18 Mar 2025·8 dk
Operasyonel Runbook'ları Yönetmek İçin Bir Web Uygulaması Nasıl Oluşturulur
Runbook yönetimi için web uygulaması oluşturma adımları: veri modeli, editör, onaylar, arama, izinler, denetim kayıtları ve olay müdahalesi entegrasyonları.
Runbook yönetimi için web uygulaması oluşturma adımları: veri modeli, editör, onaylar, arama, izinler, denetim kayıtları ve olay müdahalesi entegrasyonları.
Özelliklere veya teknoloji yığınına karar vermeden önce, organizasyonunuzda “runbook”un ne anlama geldiği konusunda uzlaşın. Bazı ekipler runbookları olay müdahale playbookları (yüksek baskı, zaman hassas) için kullanır. Diğerleri standard operating procedure (tekrarlanabilir görevler), planlı bakım veya müşteri destek iş akışları kastediyor olabilir. Kapsamı baştan tanımlamazsanız, uygulama her belge türüne hizmet etmeye çalışır ve hiçbirine iyi hizmet edemez.
Uygulamanın barındırmasını beklediğiniz kategorileri ve her biri için kısa bir örnek yazın:
Ayrıca asgari standartları tanımlayın: zorunlu alanlar (sahip, etkilenen servisler, son gözden geçirme tarihi), “tamam” ne anlama gelir (her adım işaretlenmiş, notlar alınmış) ve kaçınılması gerekenler (taranması zor uzun anlatılar).
Birincil kullanıcıları ve o anda neye ihtiyaçları olduğunu listeleyin:
Farklı kullanıcılar farklı şeyleri optimize eder. Nöbet senaryosu için tasarlamak genellikle arayüzün basit ve öngörülebilir kalmasını zorunlu kılar.
Hızlı yanıt, tutarlı yürütme ve daha kolay incelemeler gibi 2–4 temel çıktı seçin. Ardından takip edebileceğiniz metrikleri ekleyin:
Bu kararlar gezinmeden izinlere kadar sonraki her tercihe rehberlik etmelidir.
Teknolojik yığını seçmeden veya ekran taslağı çizmeye başlamadan önce, bir şey bozulduğunda operasyonların gerçekte nasıl çalıştığını izleyin. Bir runbook yönetimi web uygulaması, insanların nerede çözüme baktığını, bir olay sırasında “yeterince iyi”nin ne anlama geldiğini ve herkes aşırı yüklendiğinde nelerin göz ardı edildiğini işleyen alışkanlıklara uyduğunda başarılı olur.
Nöbet mühendisleri, SRE'ler, destek ve servis sahipleriyle görüşün. Genel görüşler yerine spesifik yakın tarih örnekleri isteyin. Yaygın acı noktaları arasında dağınık belgeler, üretimle eşleşmeyen eskimiş adımlar ve belirsiz sahiplik (kimsenin bir değişiklik sonrası runbooku güncellemekten sorumlu olmadığını bilmemesi) bulunur.
Her acı noktasını kısa bir hikâye ile yakalayın: ne oldu, ekip ne denedi, ne yanlış gitti ve ne yardımcı olurdu. Bu hikâyeler daha sonra kabul kriterleri olur.
Runbookların ve SOP'lerin bugün nerede tutulduğunu listeleyin: wiki'ler, Google Dokümanlar, Markdown depoları, PDF'ler, bilet yorumları ve olay sonrası raporlar. Her kaynak için not alın:
Bu, toplu bir aktarım aracı mı yoksa basit kopyala/yapıştır geçişi mi gerektiğini söyleyecektir.
Tipik yaşam döngüsünü yazın: oluştur → incele → kullan → güncelle. Her adımda kimlerin yer aldığına, onayların nerede olduğuna ve güncellemeleri tetikleyen olaylara (servis değişiklikleri, olay öğrenimleri, üç aylık incelemeler) dikkat edin.
Düzenlenmiş bir sektörde olmasanız bile ekipler genellikle “kim neyi, ne zaman ve neden değiştirdi” sorularına cevap ister. Minimum denetim izi gereksinimlerini erkenden tanımlayın: değişiklik özetleri, onaylayan kişi, zaman damgaları ve olay müdahale playbooku yürütülürken sürümler arasında karşılaştırma yeteneği.
Bir runbook uygulaması, veri modeli operasyon ekiplerinin gerçek çalışma şekline uyup uymadığına bağlı olarak başarılı ya da başarısız olur: birçok runbook, paylaşılan yapı taşları, sık düzenlemeler ve o an geçerli olanın güvenilirliği gerekir. Temel nesneleri ve ilişkilerini tanımlayarak başlayın.
En azından şu nesneleri modelleyin:
Runbooklar nadiren yalnız yaşar. Uygulamanın gerekli dokümanı baskı altında doğru şekilde gösterebilmesi için bağlantılar planlayın:
Sürümleri sadece eklenen kayıtlar olarak ele alın. Bir Runbook, current_draft_version_id ve current_published_version_id'ye işaret etsin.
Adımlar için içeriği Markdown (basit) veya yapılandırılmış JSON blokları (kontrol listeleri, çağrılar ve şablonlar için daha iyi) olarak saklayın. Ekleri veritabanının dışında tutun: meta veriyi (dosya adı, boyut, content_type, storage_key) saklayın ve dosyaları nesne depolamada tutun.
Bu yapı, güvenilir denetim izleri ve sorunsuz bir yürütme deneyimi için sizi hazırlar.
Runbook uygulaması baskı altında öngörülebilir kaldığında başarılı olur. Yazma, yayınlama ve güvenilir şekilde kullanma döngüsünü destekleyen minimum uygulanabilir ürünü (MVP) tanımlayarak başlayın.
İlk sürümü sıkı tutun:
Bu altı şeyi hızlıca yapamıyorsanız, ekstra özellikler işe yaramayacaktır.
Temel stabil olduğunda kontrol ve içgörüyü artıran yetenekleri ekleyin:
Operatörlerin nasıl düşündüğüyle UI haritasını eşleştirin:
Kullanıcı yolculuklarını rollere göre tasarlayın: oluşturup yayınlayan bir yazar, arayıp yürütüp yanıt veren bir müdahaleci ve güncel ile eski olanları inceleyen bir yönetici.
Doğru yazma biçimini en kolay yol haline getiren bir editör tasarlayın. İnsanlar temiz, tutarlı adımları hızla oluşturabilirse, runbooklar stres altında ve zaman kısıtlıyken de kullanılabilir kalır.
Üç yaygın yaklaşım vardır:
Birçok ekip blok editörle başlayıp kritik adım türleri için form benzeri kısıtlar ekler.
Tek bir uzun belge yerine runbooku sıralı adımlar listesi olarak saklayın; adım türleri olabilir:
Türlendirilmiş adımlar tutarlı render, arama, güvenli yeniden kullanım ve daha iyi yürütme UX sağlar.
İçeriğin okunabilir ve uygulanabilir kalmasını sağlayan zorunluluklar:
Triyaj, geri alma, olay sonrası kontroller gibi yaygın desenler için şablonlar ve yapıyı kopyalayıp önemli alanları (servis adı, nöbet kanalı, panolar) güncellemeyi isteyen Runbook'u çoğalt eylemi destekleyin. Yeniden kullanım varyasyonu azaltır; varyasyon hataların kaynağıdır.
Runbooklar insanlar tarafından güvenirlikle kullanıldığında işe yarar. Hafif bir yönetişim katmanı—açık sahipler, öngörülebilir bir onay yolu ve yinelenen gözden geçirmeler—içeriği doğru tutar, ancak her düzenlemeyi tıkanıklığa dönüştürmez.
Ekiplerin çalışma şekline uyan az sayıda durumla başlayın:
UI'da geçişleri açık yapın (ör. “İnceleme isteği”, “Onayla & yayınla”) ve kim hangi eylemi ne zaman yaptı kaydedilsin.
Her runbookta en az şunlar olmalı:
Sahipliği operasyonel nöbet konsepti gibi ele alın: sahipler ekip değiştikçe değişir ve bu değişiklikler görünür olmalıdır.
Yayımlanmış bir runbook güncellendiğinde kısa bir değişiklik özeti ve gerekiyorsa “Bu adımı neden değiştiriyoruz?” gibi zorunlu bir yorum isteyin. Bu, gözden geçiriciler için ortak bağlam yaratır ve onay sürecindeki geri dönüşleri azaltır.
Runbook incelemeleri ancak insanlar hatırlatıldığında işler. “İnceleme istendi” ve “inceleme yakında” için hatırlatmalar gönderin, ancak e-posta veya Slack'e sert bağlı kalmayın. Basit bir bildirim arayüzü (olaylar + alıcılar) tanımlayın, sonra sağlayıcıları daha sonra takın—bugün Slack, yarın Teams—çekirdek mantığı yeniden yazmadan.
Runbooklar genellikle geniş paylaşılmasını istemeyeceğiniz bilgiler içerir: dahili URL'ler, yükseltme irtibatları, kurtarma komutları ve bazen hassas yapılandırma detayları. Kimlik doğrulama ve yetkilendirmeyi temel bir özellik olarak görün, sonra güçlendirme görevini ertelemeyin.
En azından üç rol uygulayın:
Bu roller UI genelinde tutarlı olsun (düğmeler, editör erişimi, onaylar) böylece kullanıcıların ne yapabileceğini tahmin etmelerine gerek kalmasın.
Çoğu kuruluş operasyonu ekip veya servis bazlı organize eder ve izinler bu yapıyı takip etmelidir. Pratik bir model:
Daha yüksek riskli içerik için isteğe bağlı bir runbook düzeyi geçersiz kılma (ör. “sadece Database SRE'leri bu runbooku düzenleyebilir”) ekleyin. Bu, sistemi yönetilebilir tutarken istisnalara izin verir.
Bazı adımlar yalnızca daha küçük bir grup tarafından görülebilir olmalıdır. “Hassas detaylar” gibi kısıtlı bölümler destekleyin; görüntüleme için yükseltilmiş izin gerektirsin. İçeriği silmek yerine gizlemeyi tercih edin (“görüntüleyiciler için gizli”) böylece baskı altındaki runbook hala tutarlı okunur.
E-posta/parola ile başlasanız bile kimlik katmanını ileride SSO eklemeye (OAuth, SAML) elverişli tasarlayın. Kimlik sağlayıcıları için takılabilir bir yaklaşım kullanın ve sahiplik, onaylar veya denetim izleri bozulmasın diye stabil kullanıcı kimliklerini saklayın.
Bir şey bozulduğunda kimse dokümanlarda gezinmek istemez. Uyarıdan veya bir mesaja dayanan belirsiz bir terimi hatırlasalar bile doğru runbooku saniyeler içinde istiyorlar. Bulunabilirlik bir ürün özelliğidir, hoş bir ek değil.
Tek bir arama kutusu uygulayın ve başlıklardan daha fazlasını tarayın. Başlıkları, etiketleri, sahip servisi ve adım içeriğini (komutlar, URL'ler, hata dizeleri dahil) indexleyin. İnsanlar sıkça bir log snippet'i veya alarm metni yapıştırır—adım düzeyi arama bunu eşleşmeye dönüştürür.
Toleranslı eşlemeyi destekleyin: kısmi kelimeler, yazım hataları ve önek sorguları. Sonuçları vurgulanmış snippetlerle döndürün ki kullanıcılar beş sekme açmadan doğru prosedürü teyit edebilsin.
Arama, kullanıcıların bağlamı daraltabildiğinde en hızlıdır. Operasyon ekiplerinin düşündüğü şekilde filtreler sağlayın:
Filtreleri nöbet kullanıcıları için oturmalı yapın ve neden sonuçların eksik olduğunu açıklayan aktif filtreleri belirgin gösterin.
Ekipler tek bir sözlük kullanmaz. “DB”, “database”, “postgres”, “RDS” ve dahili bir lakap aynı şeyi ifade edebilir. Yeniden dağıtmadan güncelleyebileceğiniz hafif bir eşanlamlı sözlüğü ekleyin (yönetim UI'sı veya yapılandırma). Arama sırasında terimleri genişletmek için kullanın ve isteğe bağlı olarak indeksleme zamanında da uygulayın.
Ayrıca eşanlamlıları reel olay başlıkları ve uyarı etiketlerinden yakalayarak güncel tutun.
Runbook sayfası bilgi yoğun fakat taranabilir olmalı: net bir özet, önkoşullar ve adımlar için içerik tablosu. Üstte ana meta verileri (servis, uygulanabilir ortam, son gözden geçirme, sahip) gösterin; adımları kısa, numaralı ve katlanabilir tutun.
Komutlar ve URL'ler için “kopyala” kolaylığı ve ortak takipler için kompakt “ilişkili runbooklar” alanı ekleyin (ör. geri alma, doğrulama, yükseltme).
Yürütme modu runbooklarınızı “dokümantasyon” olmaktan güvenilir bir araca dönüştürür. Bunu adım adım rehberlik eden, dikkat dağıtmayı azaltan bir görünüm olarak düşünün; aynı zamanda gerçekte ne yapıldığını kaydetsin.
Her adımın net bir durumu ve basit bir kontrol yüzeyi olmalı:
Küçük dokunuşlar yardımcı olur: mevcut adımı sabitle, “sonraki”yi göster ve uzun adımları katlanabilir tut.
Yürütme sırasında operatörlerin sayfadan ayrılmadan bağlam eklemesi gerekir. Adım başına şunlara izin verin:
Bu eklemeler otomatik olarak zaman damgalı olmalı ve yürütme duraklatılıp devam ettirilse bile korunmalıdır.
Gerçek prosedürler lineer değildir. Bir runbookun koşullara uyum sağlaması için “if/then” dallanma adımlarını destekleyin (ör. “Eğer hata oranı %5'in üzerindeyse then…”). Ayrıca açık Dur & yükselt eylemleri ekleyin ki bu eylemler:
Her yürütme değiştirilemez bir kayıt oluşturmalı: kullanılan runbook sürümü, adım zaman damgaları, notlar, kanıtlar ve nihai sonuç. Bu, post-incident incelemeleri ve runbooku iyileştirmek için birincil kaynak olur.
Bir runbook değiştiğinde olay anındaki soru genellikle “en son sürüm hangisi?” değil, “ona güvenebilir miyiz ve buraya nasıl geldi?” olur. Açık bir denetim izi runbookları düzenlenebilir notlardan ziyade güvenilir operasyon kayıtlarına dönüştürür.
En azından her anlamlı değişikliği kim, ne ve ne zaman ile kaydedin. Bir adım daha atıp içerik için önce/sonra anlık görüntüler (veya yapılandırılmış diff) saklayın ki gözden geçiriciler tam olarak ne değiştiğini tahmin etmek zorunda kalmasın.
Düzenleme dışında şu olayları da yakalayın:
Bu, post-incident incelemeleri ve uyumluluk kontrolleri için güvenilir bir zaman çizelgesi oluşturur.
Her runbook için kronolojik bir değişiklik akışı gösteren bir Denetim sekmesi sunun; filtreler (editör, tarih aralığı, olay türü) ekleyin. “Bu sürümü görüntüle” ve “şimdiyle karşılaştır” eylemleri ekleyin ki müdahaleciler takip ettikleri prosedürün doğru olduğunu hızla teyit edebilsin.
Gerekirse CSV/JSON gibi dışa aktarma seçenekleri ekleyin. Dışa aktarmaları izinli ve kapsamlı tutun (tek runbook veya zaman aralığı) ve yönetim için bir sayfadan erişim sunmayı düşünün (ör. /settings/audit-exports görsel metni).
Gereksinimlerinize uygun saklama kuralları tanımlayın: örneğin tam anlık görüntüleri 90 gün sakla, sonra difflar ve meta veriyi 1–7 yıl arası sakla. Denetim kayıtlarını eklenemez (append-only) tutun, silmeyi kısıtlayın ve herhangi bir yönetimsel istisnayı da denetlenebilir bir olay olarak kaydedin.
Runbooklarınız uyarıyı tetikleyen kaynağa bir tık uzaklıktayken çok daha faydalıdır. Entegrasyonlar olay sırasında bağlam değiştirmeyi azaltır; insanlar stresliyken bunu ister.
Çoğu ekip ihtiyaçların %80'ini iki desenle karşılayabilir:
Minimal gelen yük, şu kadar küçük olabilir:
{
"service": "payments-api",
"event_type": "5xx_rate_high",
"severity": "critical",
"incident_id": "INC-1842",
"source_url": "https://…"
}
(Kod bloğu olduğu için içeriği olduğu gibi koruyun.)
URL şemanızı bir uyarının en iyi eşleşmeye doğrudan işaret edebilmesi için tasarlayın; genellikle servis + olay türü (veya database, latency, deploy gibi etiketler) ile. Örneğin:
/runbooks/123/runbooks/123/execute?incident=INC-1842/runbooks?service=payments-api&event=5xx_rate_highBu, uyarı sistemlerinin bildirime URL eklemesini kolaylaştırır ve insanların ekstra arama yapmadan doğru checklist'e inmelerini sağlar.
Slack veya Microsoft Teams ile entegre edin ki müdahaleciler şunları yapabilsin:
Entegrasyon dokümanlarınız varsa UI'da bunlara bağlanın (ör. /docs/integrations görsel metni) ve yapılandırmayı beklenen yerde (ayarlar sayfası ve hızlı test butonu) sunun.
Runbook sistemi operasyonel güvenlik ağınızın bir parçasıdır. Onu diğer üretim servisleri gibi yönetin: öngörülebilir şekilde dağıtın, yaygın hatalardan koruyun ve küçük, düşük riskli adımlarla iyileştirin.
Operasyon ekibinizin destekleyebileceği bir barındırma modeliyle başlayın (yönetilen platform, Kubernetes veya basit bir VM). Ne seçerseniz seçin, bunun kendi runbookunu dokümante edin.
Yedeklemeler otomatik ve test edilmiş olmalı. Sadece “snapshot alın” demek yeterli değil—geri döndürebileceğinizden emin olmanız gerekir:
Felaket kurtarma hedeflerinizi baştan belirleyin: kaybedebileceğiniz veri miktarı (RPO) ve uygulamayı ne kadar hızlı geri almanız gerektiği (RTO). DNS, gizli anahtarlar ve doğrulanmış geri yükleme prosedürünü içeren hafif bir DR checklisti tutun.
Runbooklar baskı altında en değerli olduğundan hızlı sayfa yüklemeleri hedefleyin:
Ayrıca yavaş sorguları erken kaydedin; sonradan tahmin etmekten daha iyidir.
Kırıldığında riskli davranışa yol açan özelliklere odaklanın:
“Runbook yayınla” ve “runbook yürüt” gibi küçük bir uçtan uca test seti ekleyin.
Önce bir ekipte pilot uygulayın—ideal olarak sık nöbet işi olan grup. Araç içinde kısa geri bildirim toplayın ve kısa haftalık incelemeler yapın. Kademeli olarak genişletin: sonraki ekibi ekleyin, bir sonraki SOP setini taşıyın ve şablonları gerçek kullanım üzerinden iyileştirin.
Konseptten çalışan bir dahili araca hızlıca geçmek isterseniz, sohbet tabanlı bir prototipleme platformu olan Koder.ai sizi uçtan uca hızlıca prototipleme aşamasına taşıyabilir. Kütüphane → editör → yürütme modu gibi temel iş akışlarında iterasyon yapıp, hazır olduğunuzda kaynak kodunu dışa aktarabilirsiniz; sonra gözden geçirme, sertleştirme ve standart mühendislik süreçleriniz içinde çalıştırma size kalır.
Koder.ai bu ürün türü için pratik çünkü yaygın uygulama seçimleriyle (web UI için React; arka uç için Go + PostgreSQL) uyumlu ve planlama modu, anlık görüntüler ve geri alma gibi özellikleri destekler—sürümlendirme, RBAC ve denetim izleri gibi operasyonel açıdan kritik özellikleri yinelemeye yarar.
Önceden kapsamı tanımlayın: olay müdahale playbookları, SOP'ler, bakım görevleri veya destek iş akışları mı olacak?
Her runbook türü için minimum standartları belirleyin (sahip, ilgili servis(ler), son gözden geçirme tarihi, “tamam” kriterleri ve kısa, taranabilir adımlara öncelik). Bu, uygulamanın sıradan doküman çöplüğüne dönüşmesini engeller.
2–4 temel çıktıyı seçip ölçülebilir metrikler ekleyin:
Bu metrikler hangi özelliklerin öncelikli olduğunu belirlemenize ve uygulamanın gerçekten operasyonları iyileştirip iyileştirmediğini görmenize yardımcı olur.
Gerçek iş akışlarını ve olay anındaki davranışları gözlemleyin, sonra şunları yakalayın:
Bu hikâyeleri arama, düzenleme, izinler ve sürümlendirme için kabul kriterlerine dönüştürün.
Temel nesneleri modelleyin:
Gerçeklik gerektirdiğinde çoktan-çoğa bağlantılar kullanın (runbook↔servis, runbook↔etiketler) ve entegrasyonların doğru playbook'u önermesi için uyarı kurallarına/olay türlerine referanslar saklayın.
Sürümleri eklenemez, değiştirilemez kayıtlar olarak ele alın.
Pratik bir desen: Runbook şu referanslara sahip olsun:
current_draft_version_idcurrent_published_version_idDüzenleme yeni taslak sürümler oluşturur; yayınlama bir taslağı yeni bir yayımlanmış sürüme dönüştürür. Eski yayımlanmış sürümleri inceleme ve post-mortem için saklayın; taslak geçmişini yalnızca gerekirse budayabilirsiniz.
MVP'nizin çekirdeği şu döngüyü güvenilir şekilde desteklemeli:
Eğer bu altı şey hızlı ve net değilse, şablonlar, analizler veya onay akışları gibi ek özellikler baskı altında kullanılmayacaktır.
Takımınıza uyan bir düzenleyici seçin:
Adımları birincil nesneler olarak modelleyin (komut/link/karar/kontrol-listesi/uyarı) ve zorunlu alanlar, bağlantı doğrulaması ve yürütme moduna uygun önizleme gibi kılavuzlar ekleyin.
Olay müdahalesi ve rutin işler için dikkat dağıtıcı olmayan bir checklist görünümü kullanın:
Her yürütmeyi, kullanılan runbook sürümüne bağlı değiştirilemez bir yürütme kaydı olarak saklayın.
Aramayı birincil ürün özelliği olarak uygulayın:
Runbook sayfasını taramaya uygun tasarlayın: kısa adımlar, güçlü meta veriler, kopyala düğmeleri ve ilgili runbooklar.
Basit RBAC ile başlayın (Viewer/Editor/Admin) ve erişimi takım veya servis bazında sınıflandırın; yüksek riskli içerik için runbook düzeyinde istisnalar sağlayın.
Yönetim için ekleyin:
Denetimleri ekleyin: kim/ne/zaman, yayınlama eylemleri, onaylar ve sahiplik değişiklikleri şeklinde eklenemez olaylar olarak kaydedilsin; kimlik doğrulama ileride SSO'ya geçişe elverişli olsun.