Küçük bir yazılım ekibi için kesinti planı hazırlamak
Belirli bir kesinti için kararları, teknik işleri ve iletişimi planlayın. Bir müdahale kartı gözlemi, sorumlu rolü ve sonraki kontrolü birleştirir.
Bir kesinti planı, ekibinizin kesilen işleri düzenli biçimde ele almasına yardımcı olmalıdır. Yazılımınızdaki önemli bir akışı seçin; kesintinin nasıl anlaşılacağını, kimin karar vereceğini ve yeniden başlamak için hangi doğrulamanın gerekeceğini yazın.
Etkilenen akışı tanımlayın
Kurgusal örnekte I-72 kesintisi bir müşteri portalını etkiler. Ana sayfa yanıt verir, ancak yeni talepler dosya ekiyle birlikte tam olarak kaydedilemez. A-72 talebi ve F-72 dosyası yalnızca test örneğidir. Burada gözlemlenmiş gerçek bir işletim kesintisi değildir.
Bu durumda yalnızca ana sayfanın erişilebilir olması kapanış ölçütü sayılmaz. Plan; dosya kaydını, rol kontrolünü ve sonraki işleri içeren tam talep akışını belirtir. Müdahale sırasında hangi değişikliklere izin verildiği de kaydedilir.
Müdahale kartını rollerle doldurun
Google SRE; açık rolleri, güncel çalışma kaydını ve teyit edilmiş devirleri anlatır. Küçük ekiplerde bir kişi birden fazla rol üstlenebilir. Yine de kimin koordine ettiği, kimin sistemi değiştirdiği ve kimin bilgi verdiği görünür olmalıdır.
Örnekteki gözlem | Planlanan karar | Sorumlu rol | Sonraki doğrulama |
|---|---|---|---|
Dosya ekli talepler başarısız olur. | Kesintiyi ilan edin, etkiyi kaydedin ve müdahalenin devamını koordine edin. | Koordinasyon | Etkilenen akış ve bilinen etki çalışma kaydına yazılmıştır. |
Teknik bir değişiklik önerilir. | İşlemi ve durdurma koşulunu kararlaştırın; koordinesiz paralel değişikliklerden kaçının. | Teknik müdahale | İşlem, sorumlu kişi ve gözlemlenen sonuç belgelenmiştir. |
Olası bir kurtarma çözümü hazırdır. | Tam akışı kontrol edin ve yeniden başlama kararını açıkça verin. | İş birimi ve işletim sorumluları | Yeni talep, ek, uygun yetkiler ve açık arka plan işleri kontrol edilmiştir. |
Tablo yapılmış bir kurtarmayı değil, planlanan adımları gösterir. Bir yedek sorumlu ve ekibin çözemediği durumlarda başvuracağı ulaşılabilir bir kişi belirleyin. Çalışma belgesine portal kapalıyken de erişilebilmelidir.
İletişimi ayrı bir görev olarak planlayın
Etkilenen kişileri ve ilgili hizmetleri kimin bilgilendireceğini belirleyin. Durum bildirimi; bilinen etkiyi, mevcut müdahale durumunu ve kararlaştırılan sonraki bilgilendirme noktasını belirtir. Tahmini neden bir varsayım olarak görünür; dayanağı olmayan kurtarma süresi taahhüt olarak aktarılmaz.
Kesinti sırasında görevli değişirse mevcut durum devredilir ve yeni sorumlu devraldığını teyit eder. Başarısız işlemler ve açık kontroller de devre dahildir. Yalnızca mesaj göndermek, yeni koordinatörün görevi üstlendiğini göstermez.
Yeniden başlama ile sonraki çalışmaları ayırın
Ekip yeniden başlamadan önce etkilenen akışı, kararlaştırılan testlerle uygun ortamda kontrol eder. Önceki duruma dönmenin mümkün olup olmadığı, bu sırada değişen verilere de bağlıdır; tek başına yeniden başlatma kurtarmanın kanıtı değildir.
Yeniden başlamayı kimin onayladığını ve hangi açık işlerin izleneceğini kaydedin. Sonraki kök neden analizi planı iyileştirebilir; ilk stabilizasyonla aynı şey sayılması gerekmez. Kartı onaylanmış bir senaryoyla deneyin; eksik iletişim bilgilerini, erişimleri veya kontrol adımlarını düzeltin.
Kaynaklar
Devamını okuyun
Tüm yazılar
ASES ile Bulut ve işletim
Barındırma, yayına alma, bakım ve destek