En GitLab-grupp kan innehålla år av utvecklingsarbete och samtidigt vara beroende av en enda person för administrativa beslut. Om personen dör eller blir otillgänglig kan utvecklare kanske fortsätta skicka kod utan att någon vet vem som kan hantera gruppens åtkomst, godkänna abonnemangskostnader eller ersätta autentiseringsuppgifter för driftsättning. Familjen och kollegorna möter då olika delar av samma ofullständiga överlämning.
Planeringen börjar med en utsedd samordnare, en reservägare med testad åtkomst och en inventering av driftberoenden. Checklistan omfattar förberedelser och den första genomgången efter ett dödsfall. Identifiera om ni använder GitLab.com eller en egenförvaltad instans innan ni följer administrativa rutiner. Tekniska behörigheter är en del av kontinuiteten; dokumentera separat vem som beslutar för organisationen och vem som företräder dödsboet.
1. Kartlägg gruppen och ansvaret
Anteckna instansens URL, huvudgruppens sökväg, viktiga undergrupper, projektens platser och nuvarande mänskliga ägare. Ta med personliga namnrymder som innehåller arbete organisationen behöver, men markera dem för separat granskning. Utgå inte från att alla kodförråd en grundare skapat tillhör samma företag eller ska delas med samma efterträdare.
Utse ansvariga för gruppadministration, kodunderhåll, infrastrukturdrift och betalningsbeslut. En person kan ha flera roller, men varje roll behöver en ersättare och en kontaktväg. Dokumentera vem som godkänner känsliga ändringar och var beslutsloggen finns. Be projektledare identifiera saknade kodförråd, privat dokumentation eller instruktioner för utgåvor som en central inventering kan missa.
2. Kontrollera en tillgänglig ägares åtkomst
GitLab beskriver byte av gruppägare genom medlemskontrollerna. Gruppen måste behålla minst en människa med rollen Owner; en bot eller ett tjänstekonto får inte vara den enda ägaren. Utse vid förberedelser en andra betrodd mänsklig ägare och testa åtkomsten medan den nuvarande ägaren fortfarande kan hjälpa till.
Låt efterträdaren logga in med sitt eget konto och hitta rätt grupp. Kontrollera de administrationsfunktioner överlämningen kräver, utöver att en projektsida går att öppna. Dokumentera hur åtkomsten ges och om medlemskap hos en identitetsleverantör eller andra organisationsinställningar påverkar den. Förvara återställningsmaterial på en godkänd säker plats med instruktioner som en behörig efterträdare faktiskt kan följa.
En accepterad inbjudan är början på kontrollen. Öva på att hitta medlemsinställningar, ett kritiskt kodförråd och infrastrukturens kontaktperson. Anteckna datum och brister. Ändra inte produktionsinställningar bara för att bevisa åtkomst: en granskning av kontrollerna och en ofarlig tillåten uppgift kan visa beredskap utan att störa teamet.
3. Begär riktad hjälp vid saknad åtkomst
Om ingen har de funktioner som behövs, samla instansadress, gruppsökväg, relevanta projektadresser, kända kontoidentifierare och en nåbar organisationskontakt. Fråga GitLab Support vilken process som gäller för GitLab.com. För en egenförvaltad instans, involvera den behöriga administratören och ansvariga för hosting och identitetstjänster.
Beskriv vilken åtkomst som saknas och vilket arbete som är blockerat. Be mottagaren bekräfta vilka underlag som behövs och vilka alternativ som finns. Checklistan fastställer ingen särskild överföringspolicy efter dödsfall, ingen garanterad återställning och ingen handläggningstid. Spara förfrågningar och svar i överlämningsloggen och utse någon att följa upp, så att ärendet inte blir liggande i en obevakad inkorg.
4. Bevara mer än Git-kodförrådet
Inventera kodförråd tillsammans med ärenden, merge requests, wikier, utgåvefiler, paket, containeravbilder och viktig projektdokumentation. Bestäm vad organisationen får bevara och vem som behöver åtkomst. En lokal klon kan bevara kod men sakna diskussioner och driftinformation som förklarar hur koden underhålls.
GitLabs dokumentation om filexport beskriver inkluderade och uteslutna delar. CI/CD-variabler ingår inte i projektens filexporter. Läs dokumentationen för er version och valda metod i stället för att behandla en export som en fullständig säkerhetskopia för driften.
Varje bevarandeuppgift behöver en ansvarig person, en säker destination och en kontroll. Bekräfta att sparat material går att öppna, anteckna insamlingsdatum och dokumentera utelämnade delar. Förvara känsliga verksamhetsdata i godkänd lagring. Om återställning eller import ingår i planen, testa den i en lämplig isolerad miljö innan ni förlitar er på den vid en verklig överlämning.
5. Granska pipelines och beroenden av autentiseringsuppgifter
Lista beroenden för kritiska bygg- och driftsättningsflöden: runners, schemalagda jobb, webhooks, externa register, molntjänster, paketpublicering och signeringslösningar som faktiskt används. Identifiera anslutningar knutna till den otillgängliga personens konto och sådana som organisationen förvaltar. Anteckna platser och ansvariga för autentiseringsuppgifter utan att kopiera hemliga värden till kontinuitetsanteckningen.
GitLabs vägledning om CI/CD-variabler rekommenderar att känsliga värden lagras i inställningarna i stället för i pipeline-konfigurationsfilen. Låt behöriga operatörer granska hur nödvändiga hemligheter tillförs. Begränsa åtkomsten till dem som behöver den och undvik att exponera värden i skärmbilder, supportärenden eller jobbutdata.
Planera ersättningsuppgifter med ansvariga operatörer. Testa ett representativt bygge och vid behov en kontrollerad driftsättning innan gamla beroenden återkallas rutinmässigt. Vid tecken på intrång kan akut begränsning behöva prioriteras; dokumentera det som ännu inte testats. Målet är en genomtänkt ordning med tydligt ansvar i stället för en oförklarad samling fungerande åtkomsttoken.
6. Håll fakturering och identitetstjänster tillgängliga
Anteckna abonnemang, förnyelsedatum, fakturaplatser, betalningsgodkännare och faktureringskontakter. Kontrollera att meddelanden når en bevakad adress under organisationens kontroll. Utse någon att besluta vilka tjänster som måste fortsätta och spara bekräftelser på godkända betalningsändringar. Gruppadministration och utgiftsansvar behöver separata kontroller.
För egenförvaltad GitLab, inventera också hosting, säkerhetskopior, lagring, certifikat, domäner och instansens operatörer. Granska i båda modellerna externa identitetsleverantörer för inloggning. En fungerande GitLab-inloggning visar inte att någon kan sköta domänförnyelse, hostingavtal eller identitetsinställningar nästa månad. Ge varje beroende en efterträdare och ett granskningsdatum.
7. Slutför överlämningen före rutinmässig kontoborttagning
Granska öppna arbetsuppgifter, godkännandeansvar, integrationer och behörigt bevarande innan den avlidnes åtkomst tas bort rutinmässigt. Samordna ändringar med säkerhets- och identitetsadministratörer. Bevara upphovsangivelser och användbar projekthistorik enligt organisationens beslut om lagring; improvisera inte omfattande kontoradering som administrativ städning.
Flytta inte grupper eller ändra namnrymdssökvägar enbart för att tillsätta en administratör. Om flytten behövs av ett annat verksamhetsskäl, granska effekterna och skapa en separat ändringsplan. Koppla GitLab-anteckningen till den bredare kontinuitetsplanen för nätverksamheten och granska båda efter personal- eller infrastrukturförändringar.
Nästa steg
Utse en samordnare, inventera grupperna och testa en tillgänglig ägares åtkomst. Eskalera saknade behörigheter via rätt support- eller administrationskanal. Bevara tillåtna uppgifter, kontrollera pipeline-beroenden och fördela ansvar för fakturering och infrastruktur. Avsluta med en daterad lista över utförda uppgifter och öppna frågor. En övad plan ger kollegorna en praktisk väg framåt och lämnar färre tekniska beslut till familjen.