Kullanıcı tarafından görülebilen işlevi izleyin, teşhis etmek için yeterli kaynak ve uygulama kanıtı ekleyin ve yalnızca zamanında insan müdahalesi gerektiren durumlar için bildirim gönderin. Her uyarıyı bir sahip, bir ilk adım ve eskalasyonla eşleştirin. Bir olay sırasında hafifletmeyi koordine edin, kanıtları koruyun ve kurtarmayı gerçek kullanıcı yolculuğu üzerinden doğrulayın.
Önemli olan işlevle başlayın
Ping'e yanıt veren bir sunucu, uygulamasının çalıştığını kanıtlamaz. Genel bir sayfayı alma veya kontrollü bir test uç noktasına erişme gibi temsili ve zararsız bir kullanıcı yolculuğu seçin. Başarının nasıl göründüğünü tanımlayın ve her çalıştırmada gerçek siparişler oluşturan, içerik yayınlayan veya müşteri bildirimleri gönderen sentetik kontrollerden kaçının.
Uygulamanın içinden olduğu kadar uygun bir dış perspektiften de izleyin. Dış gözlem, sunucunun görmediği erişim veya yönlendirme sorunlarını ortaya çıkarabilir. Dahili ölçümler yolculuğun neden başarısız olduğunu açıklayabilir. Her ölçüm mevcut olduğu için büyük bir gösterge paneli toplamak yerine her iki görünümü de işleve bağlı tutun.
Tanısal değeri olan sinyalleri seçin
Google'ın SRE rehberi, kullanıcıya yönelik sistemler için gecikme, trafik, hatalar ve doygunluğu yararlı sinyaller olarak vurgular. Bunları davranışı tanımlamak için kullanın: yanıt süresi, istek hacmi, başarısız istekler ve kısıtlı kaynaklar üzerindeki baskı. Tek bir metrik tanımının bir web sitesi, bir aktarım hizmeti ve bir arka plan çalışanı için işe yaradığını varsaymak yerine uygulamaya uygun ölçümleri seçin.
Önemli olduğu yerde başarılı ve başarısız istek davranışını ayırın ve yalnızca ortalamalara değil yavaş kuyruk sonuçlarına da bakın. Hizmeti açıkladıklarında bellek baskısı, disk alanı, kuyruk derinliği veya uygulamaya özgü sınırlar ekleyin. Yararlı toplu iş sırasında yüksek bir CPU okuması normal olabilir; acil eylem gerekip gerekmediğini kullanıcı tarafından görülebilen etki belirler.
Her uyarıya bir eylem ve bir sahip verin
Bir uyarı, etkilenen işlevi, gözlemlenen durumu ve yararlı ilk kontrolü belirtmelidir. Dağıtmadan önce bir sahip ve bir eskalasyon yolu atayın. Hızlı bir kesinti gerektiren durumları planlı bir incelemeye uygun öğelerden ayırt edin. Tekrarlanan düşük değerli bildirimler, operatörleri sistemi görmezden gelmeye alıştırır ve önemli sinyallerin tanınmasını zorlaştırır.
Belirsizliği gidermek için küçük bir uyarı incelemesi kullanın. Bu örnek tablo, olası izleme kararlarını açıklar; SwissOctet destek kapsamını veya bir kullanılabilirlik taahhüdünü değil. Eşiklerin gerçek uygulamanın temeline göre test edilmesi gerekir. Operatörün uyarının ne zaman temizlendiğini ve neyin hâlâ doğrulanması gerektiğini bilmesi için bir kurtarma koşulu ekleyin.
| Gözlemlenen durum | Yararlı yanıt | Eklenecek bağlam |
|---|---|---|
| Temsili kullanıcı yolculuğu başarısız oluyor | Etkiyi değerlendirin ve hafifletin | Etkilenen uç nokta, süre ve son değişiklik |
| Disk planlanan sınıra yaklaşıyor | Büyümeyi ve saklamayı gözden geçirin | Hacim, büyüme oranı ve güvenli boş alan |
| Yedekleme doğrulaması başarısız oluyor | Kurtarma yolunu koruyun | İş, son kullanılabilir nokta ve hata |
| Bir sürüm sırasında gecikme artıyor | Değişikliği inceleyin veya geri alın | Temel, sürüm zamanı ve etkilenen istekler |
Küçük bir olay yapısı hazırlayın
Bir yanıt süreci baskı altında anlaşılır olmalıdır. Olay farklı roller gerektirecek kadar büyük olduğunda bir koordinatör, teknik işleri yürüten biri ve güncellemelerden sorumlu biri belirleyin. Küçük bir proje rolleri birleştirebilir, ancak yine de tek bir net karar noktasından yararlanır. Hizmet arızalanmadan önce bir iletişim kanalı üzerinde anlaşın.
Google'ın olay müdahalesi materyali koordinasyonu ve önce hafifletme yaklaşımını vurgular. Bunu projeye uygun ölçekte uygulayın: etkiyi belirleyin, güvenli eylemleri seçin ve birkaç operatörün çelişkili değişiklikler yapmasından kaçının. Bir zaman çizelgesi ve kararları kaydedin. Mükemmel bir açıklama aramak, etkilenen işlevi geri getiren güvenli bir önlemi geciktirmemelidir.
Somut bir bozulmayı adım adım inceleyin
Bir sürümden sonra bir sitenin yavaşladığını hayal edin. Dış kontrol, tamamlanma süresinin arttığını gösterirken dahili ölçümler uygulama hatalarını ve artan veritabanı işini gösterir. Koordinatör sınırlı bir olay ilan eder, kanıtları korur ve bir kişiyi sürümü temel ile karşılaştırmakla görevlendirir. Bir diğeri, ilgisiz altyapı değişiklikleri yapmak yerine test edilmiş geri alma yolunu hazırlar.
Geri alma, uygulamanın veri durumu için güvenliyse bunu kullanın ve sonucu gözlemleyin. Güvenli değilse, işletim planı tarafından desteklenen daha dar bir hafifletme seçin. Neyin ve ne zaman değiştiğini belgeleyin. Daha büyük bir VPS veya bağlantı noktası daha sonra değerlendirmeye değer olabilir, ancak acil karar, altyapı boyutunun neden olduğunu varsaymak yerine kanıtları ele almalıdır.
Kanıtları koruyun ve kurtarmayı doğrulayın
Operasyonel günlükler ve olay notları adresler, tanımlayıcılar ve müşteri bilgileri içerebilir. Soruşturmanın ihtiyaç duyduğu şeyleri toplayın, erişimi sınırlayın ve kimlik bilgilerini veya özel sipariş belirteçlerini paylaşılan raporların dışında tutun. Şüpheli bir güvenlik olayı için, aceleyle temizlik yaparak bilgileri yok etmek yerine uygun kanıtları koruyun ve projenin yanıt politikasını izleyin.
NIST'in olay müdahalesi rehberi, müdahaleyi daha geniş siber güvenlik risk yönetimi içine yerleştirir. Kurtarma, amaçlanan işlevi kontrol etmeyi ve olayı mümkün kılan koşulu çözmeyi içerir. Müdahaleyi kapatmadan önce kullanıcı yolculuğunu test edin, kaynak davranışını gözden geçirin ve arka plan işlerini kontrol edin. Yalnızca temizlenmiş bir uyarı veya yeniden başlatılmış bir süreç, yararlı hizmete tam bir dönüşü kanıtlamayabilir.
Olayı ölçülebilir bir iyileştirmeye dönüştürün
Etki, zaman çizelgesi, katkıda bulunan koşullar ve alınan önlemler hakkında kısa bir inceleme yazın. Doğrulanabilen değişikliklere odaklanın: bir kontrolü iyileştirin, bir izni düzeltin, geri almayı prova edin veya eksik bir kurtarma bağımlılığı ekleyin. Sahipleri ve tamamlanma ölçütlerini atayın. Kimsenin daha sonra uygulandığını doğrulayamayacağı uzun bir belirsiz niyetler listesinden kaçının.
SwissOctet üzerinde dağıtım yaparken, izleme ve yanıtı seçilen donanımdan ve onaylanmış herhangi bir yönetim düzenlemesinden ayrı olarak uygulamanın işleyişinin bir parçası olarak planlayın. Katalog, kadrolu bir olay ekibi veya sürekli destek saatleri oluşturmaz. Bir üretim ortamına güvenmeden önce uyarıları kimin alacağına, kimin harekete geçebileceğine ve gerçek hizmet koşullarının neleri kapsadığına karar verin.
Pratik kontrol listeniz.
- Zararsız, temsili bir kullanıcı yolculuğunu izleyin.
- Uygulama davranışını açıklayan sinyalleri seçin.
- Uyarılara bir eylem, sahip ve kurtarma koşulu verin.
- Bir olaydan önce koordinasyon ve eskalasyon üzerinde anlaşın.
- Kanıtları koruyun ve tam kurtarmayı doğrulayın.
- İncelemeden sonra test edilebilir iyileştirmeler atayın.
Önemli olan ayrıntılar.
Sunucu çalışma süresi izlemesi yeterli mi?+
Hayır. Erişilebilir bir makine bozuk bir uygulamayı barındırabilir. Kullanıcıların bağlı olduğu işlevi izleyin ve arızaları teşhis etmek için kaynak kanıtı ekleyin.
Her metrik eşiği birine hemen bildirim göndermeli mi?+
Hayır. Acil kesintileri zamanında dikkat gerektiren eyleme geçirilebilir durumlara ayırın. Daha düşük öncelikli işleri net bir sahibi olan bir inceleme sürecine yönlendirin.
Bir olay ne zaman biter?+
Etkilenen işlev ve ilgili arka plan işleri doğrulandıktan, acil riskler ele alındıktan ve takip eylemleri kaydedildikten sonra. Yalnızca bir süreci yeniden başlatmak yeterli değildir.
Kaynağa gidin.
Bu kaynaklar, bu kılavuzdaki teknik kavramları destekler. Bir üretim sistemini değiştirmeden önce güncel belgeleri izleyin.
- Google SRE: Dağıtılmış sistemleri izleme sre.google
- Google SRE Çalışma Kitabı: Olay müdahalesi sre.google
- NIST SP 800-61 Rev. 3: Olay müdahalesi csrc.nist.gov
SwissOctet tarafından editoryal rehberlik. Örnekler açıklayıcıdır. Hizmet spesifikasyonları, mevcut seçenekler ve sözleşme koşulları ayrıca doğrulanmalıdır.