Servis Runbook Web Sitesi Tasarımı

Auth-Service Runbook Tasarımı

Resmî OpenDesign web sitesi örneği olan bu çalışma, Northwind kimlik servisi runbook'unu tek bir operasyonel referans olarak sunar. Yazılmış başlık “auth-service”tir; ardından sahiplik, sürüm, gözden geçirme tarihi ve “TIER 0 · PRODUCTION-CRITICAL” durumu gelir. Bu açılış, okur uyarılara veya komutlara ulaşmadan önce servisin sorumluluğunu ortaya koyar.

Servis özeti; web, mobil ve herkese açık API genelinde oturum belirteci üretimini, doğrulamasını ve iptalini adlandırır. Ayrıca parola deposunu, TOTP/WebAuthn kayıtlarını ve denetim günlüğü kayıt bileşenini belirtir. Bu, sayfayı yönlendirme açısından yararlı kılar: müdahale eden kişi, bir prosedür seçmeden önce servise ait müşteriye dönük ve güvenlikle ilgili sorumlulukları görebilir.

Desteklenen Operasyonel Görevler

Tasarım, birbiriyle ilişkili birkaç görevi ayrı sayfalara bölmeden destekler. Sıralama servis kapsamından bağımlılıklara, ardından uyarılara, prosedürlere, nöbet kapsamına ve olay müdahalesine ilerler. Bu sıra, bir uyarıyı tek başına yorumlama ihtiyacını azaltır: okur önce servisin neye sahip olduğunu, sonra bir parça aksadığında nasıl müdahale edeceğini öğrenir.

Bağımlılık listesi Postgres, Redis, KMS, SES ve Pager için ad ve durum kalıbını tekrarlar. Dört kayıt sağlıklı, SES · transactional ise düşük performanslı olarak işaretlenmiştir. Sağa hizalı durumlar taramayı kolaylaştırır, ancak bunlar örnek tasarımın bir anlık görüntüsüdür; kanıtlanmış canlı sağlık kontrolleri değildir.

Uyarıdan Prosedüre

Uyarı bölümü dört sütunlu bir karar yüzeyi olarak tasarlanmıştır: uyarı, önem derecesi, ne anlama geldiği ve ilk müdahale. Örneğin “auth.login_5xx_rate greater than 1%”, “SEV-1” ile, müşteri hesabı kilitlenmesi açıklamasıyla ve Postgres ile Redis panolarını inceleme yönergesiyle eşleştirilmiştir. Açık eşik müdahale edene bir tetikleyici sağlarken metin yorumu sunar; ödünleşim şudur: gerçek bir runbook'ta örnek değerlerin yine de doğrulanmış bir izleme kaynağına ihtiyacı vardır.

Prosedür bölümü, kompakt satırlardan başlık, kullanım notu, açıklayıcı cümle ve komut paneli içeren büyük bloklara geçerek ritim değiştirir. “Deploy a new version”, akışın blue/green olduğunu ve geçişten önce art arda iki sağlık kontrolünü beklediğini belirtir. Görünen trafik sırası “10% / 50% / 100%” kademeli dağıtımı anlatır; büyük blok ise komut düzeyinde daha güvenli okuma karşılığında daha fazla dikey alan kullanır.

Komutlar ve Kısıtlar

Prosedür blokları aksiyonu ve uyarıyı yan yana tutar. Geri alma, dağıtım sonrası hata oranı %1'i aştığında kullanılmak üzere etiketlenmiştir; imzalama anahtarı rotasyonu ise “Schedule with security; never solo” der. Denetim günlüğü prosedürü açıkça birikim uyarısına bağlanmıştır. Bu eşleşmeler yararlı bir bilgi tasarımı tercihini gösterir: komut tek başına yeterliymiş gibi sunulmaz, çevresindeki koşul ise iş akışında ne zaman yer alacağını belirler.

Olay Sırası ve Yetenek Sınırı

Son olay müdahalesi bölümü ilk otuz dakikayı numaralı beş karta dönüştürür. Sıra, beş dakika içinde onayla başlar, özel bir olay kanalı açar, her on dakikada bir durum özeti ister, hafifletmeye öncelik verir ve devir veya olayı kapatmayla biter. Numaralandırma amaçlanan sırayı görünür kılar; iki sütunlu düzen ilk dört aksiyonu kompakt tutarken beşinci kart yalnızca kendi içeriği kadar yer kaplar.

Bu yalnızca tasarım amaçlı bir web sitesi örneğidir. Yakalanan sayfa komutları, durumları, adları ve “rolled back to v4.7.2 in 38 s” gibi örnek sonuçları görünür biçimde sunar; ancak bu komutların çalıştığını, servislerin bağlı olduğunu veya gösterilen operasyonel sonuçların ölçüldüğünü kanıtlamaz. Uyarlamalar, belgelenmiş yönerge ile doğrulanmış çalışma zamanı verisi arasındaki ayrımı korumalıdır.

1. Çağrıyı Onaylayın

   Tasarım, /ack ve beş dakikalık müdahale penceresiyle başlar; ilk koordinasyon yükümlülüğünü belirler.

2. Olay Kanalını Açın

   İkinci kart, özel bir müdahale alanı oluşturmak için kullanılan servis adı ve kısa başlık kalıbını belirtir.

3. Durum Özeti Paylaşın

   Üçüncü kart müşteri etkisini, mevcut bilgiyi ve sonraki kontrolleri tekrarlanabilir bir güncellemede toplar.

4. Hafifletin ve Devredin

   Son iki kart geri almaya veya güvenlik yükseltmesine öncelik verir, ardından devri ve kapanışı tanımlar.