# Yararlı bir olay müdahalesine yol açan izleme oluşturun | SwissOctet Insights https://swissoctet.com/tr/insights/monitoring-incident-response-playbook/ SwissOctet / İçgörüler / İkinci gün operasyonları İkinci gün operasyonları Uygulamalı · 4 dk okuma Faydalı bir olay müdahalesine yol açan izleme oluşturun Uygulama belirtilerini, eyleme geçirilebilir uyarıları ve küçük bir müdahale kitapçığını birbirine bağlayın, böylece bir operatör bir hizmet bozulduğunda net kararlar verebilir. SwissOctet Editör Ekibi tarafından Kılavuzu kaydet Bağlantıyı kopyala BU SAYFADA 01 Önemli olan işlevle başlayın 02 Tanısal değeri olan sinyalleri seçin 03 Her uyarıya bir eylem ve bir sahip verin 04 Küçük bir olay yapısı hazırlayın 05 Somut bir bozulmayı adım adım inceleyin 06 Kanıtları koruyun ve kurtarmayı doğrulayın 07 Olayı ölçülebilir bir iyileştirmeye dönüştürün Pratik kontrol listeniz Kaynaklar ve daha fazla okuma Kütüphaneye dön DOĞRUDAN YANIT 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. 01 Ö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. 02 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. 03 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 04 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. 05 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. 06 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. 07 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. HAREKETE GEÇİRİN 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. Kontrol listesini indir SIK SORULAN SORULAR Ö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. BİRİNCİL KAYNAKLAR 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. BİLGİYİ BAĞLAYIN İlgili altyapı. Vector VPS İsviçre Metal Atlas İsviçre Transit 40 İsviçre BAĞLANTIYI KORUYUN Bir sonraki saha notlarınız. Tüm kılavuzları keşfedin SAHA NOTU / 01 + İkinci gün operasyonları Uygulamalı Gerçekten geri yükleyebileceğiniz bir yedek oluşturun Bir kurtarma hedefi seçin, bağımsız bir kopyayı koruyun ve bir olay konuyu zorlamadan önce geri yüklemeyi deneyin. 4 dk okuma Kılavuzu okuyun SAHA NOTU / 02 + İkinci gün operasyonları Uygulamalı Barındırılan projeniz için pratik bir tehdit modeli Varlıkları ve güven sınırlarını haritalayın, birkaç gerçekçi arıza senaryosu seçin ve bunları test edebileceğiniz kontrollere dönüştürün. 6 dk okuma Kılavuzu okuyun SAHA NOTU / 03 + İkinci gün operasyonları Uygulamalı Erişimi kaybetmeden güvenli Windows RDP yönetimi Ağ erişilebilirliğini, kimlik doğrulamayı ve ayrıcalığı ayırın, ardından uzaktan erişimi sıkılaştırmadan önce bir kurtarma yolunu doğrulayın. 6 dk okuma Kılavuzu okuyun