GH GambleHub

Checkout hizmetinin Kanarya sürümü

1) Neden işlem belgelerine ihtiyacım var?

Operasyonel dokümantasyon, bir kuruluşun yönetilen belleğidir: MTTR'yi azaltır, performansı standartlaştırır, denetimlerin geçmesine yardımcı olur ve kaliteyi düşürmeden ekipleri ölçeklendirir. İyi belgeler:
  • Sözlü bilgiyi tekrarlanabilir prosedürlere dönüştürür;
  • Sorumluluk sınırlarını ve tırmanma noktalarını tanımlar
  • Uyum ve güvenlik için bir kanıt kaynağı olarak hizmet eder;
  • Gemiye binmeyi hızlandırır ve'dar boyunlar "riskini azaltır.

2) Belge taksonomisi (ne nedir)

Politika: Niyet ve çerçeve ('ne ve neden "). Örnek: Olay Yönetimi Politikası.
Standart: zorunlu minimum gereklilikler ('ne kadar "). Örnek: TLS sertifika yenileme tarihleri.
SOP/Prosedür: Sıralı adımlar ('as "). Örnek: Kanarya rulosuyla serbest bırakın.
Runbook: Tipik olaylar için adım adım talimatlar (uyarılar/işlemler). Örnek: "API 5xx büyüdü - eylemlerin algoritması".
Playbook: Seçenekleri ve çatalları olan bir dizi senaryo çözümü. Örnek: "Ödeme sağlayıcısıyla ilgili sorunlar".
KB (Bilgi Bankası): cevaplar, SSS'ler, araç yardımı.
Kontrol listesi - eylemlerden önce gerekli öğelerin kısa bir listesi.
Kayıt/Kanıt: Tamamlanan adımların günlüğü, ekran görüntüleri/günlükler/imzalar.

💡 Kural: Politika/Standart yavaş yavaş değişiyor, SOP/Runbook/Playbook - sık sık gelişiyor ve Git'te yaşıyor.

3) İyi dokümantasyon ilkeleri

Tek Doğruluk Kaynağı (SSOT) Belgeler çoğaltılmaz; Sprey eski haline gelir.
Kod olarak dokümanlar. Git'te saklıyoruz, kod incelemesini geçiyoruz, sürümler ve dağıtımlar görülebilir.
Önce eyleme geçilebilir. Başlangıçta - kısa bir kart: ne zaman başlayacak, sahibi kim, ne yapmalı, tamamlama kriterleri.
Atomiklik ve adreslenebilirlik. Bir belge - bir görev/süreç.
Güncellenebilirlik. Sahibi ve SLA güncellemelerini temizleyin (örn. Üç ayda bir).
Gözlenebilirlik. Panolara/uyarılara/metriklere bağlantılar gömülüdür.
Tasarım gereği güvenlik. Hassasiyet sınıflandırması, gizli maskeleme, erişim kontrolü.

4) Belge yaşam döngüsü (Yönetişim)

1. Initiation: application/ticket - document type - owner.
2. Taslak: şablon, minimum örnekler, standartlara ve SLO'ya referanslar.
3. İnceleme: teknik (SRE/platform/güvenlik), prosedürel (süreç yöneticisi).
4. Yayın: ana dalda, sürümü/tarihi işaretleyerek, durumu atayarak (aktif/deneysel/kullanımdan kaldırılmış).
5. Eğitim/İletişim: değişikliklerin duyurulması, kısa eğitim/demo.
6. Retrospektif: Olayların/egzersizlerin sonuçlarına dayanarak, değişiklikler yapın.
7. Denetim ve arşiv: değişmez iz (kim/değiştirildiğinde), arşivdeki eski sürümler.

5) SOP/Runbook yapısı (minimum)

1. Kart: İsim, Kimlik, Sürüm/Tarih, Sahip, Sorumlu Roller, İlgili Politikalar/Standartlar.
2. Ne zaman başvurulur: başlangıç koşulları (uyarı/olay/çalışma penceresi).
3. Hazırlık: haklar/araçlar/veriler, risk değerlendirmesi, iletişim.
4. Adımlar: Numaralandırılmış, komutlar/ekran görüntüleri/beklenen sonuçlar.
5. Başarı/geri alma kriterleri: açık SLI/SLO eşikleri.
6. Eskalasyon: kim, ne zaman ve nasıl (kanal, telefon, sağlayıcı).
7. Güvenlik/uyumluluk: hassas veriler, yasaklar, eylemlerin kayıtları.
8. Eylemler sonrası: biletlerin kapatılması, durumun güncellenmesi, kanıt toplanması.
9. Değişikliklerin tarihi (changelog).

6) Stil ve tasarım kuralları

Açık ve kısa: 1 adım - 1 eylem - 1 sonuç.
Zorunlu: "Execute"..., "Check"..., "Roll back"....
Ekran görüntüleri/komutlar: adımın yanında; komutlar kopyalanan bloklar; Beklenen çıktıyı not edin.
Değişkenlik: dallar "Eğer A? X adımı, eğer B? Y adımı".
Kohort: ilgili olduğunda - bölgeleri/sağlayıcıları/kiracıları belirtin.
Yerelleştirme: anahtar belgeler - en az 2 dil; Çevirilerin durumunu belirtin.
Etiketler ve arama: servis, bileşen, sağlayıcı, olay türü, SLO, sürüm.

7) Docs-as-Code ve Araçları

Depolama: Git (main/feat/bugfix), PR incelemesi, gerekli kontroller.
Biçim: Markdown/AsciiDoc; PlantUML/Mermaid JSON/YAML şemalarındaki grafikler.
Yayın: Statik site (Docusaurus/MkDocs) + arama.
Doğrulama: CI-tiftik, bağlantı testi, yazım, kod bloğu doğrulayıcıları.
Entegrasyonlar: ChatOps komutları'/runbook open X ', uyarılarda en son sürümü görüntüler.
Bağlantılar: CMDB/hizmet kataloğu ↔ dokümantasyon ↔ gösterge tabloları.

8) Erişim kontrolü ve sınıflandırma

Классы: Genel/Dahili/Gizli/Kısıtlı.
Ayırma: genel talimatlar (genel durumlar) vs özel (tuşlar, komutlar, ağ diyagramları).
Sırlar: metinde yasaktır; Gizli depolama ve yer tutucuları kullanın.
Denetim - Hassas SOP'lar için okuma/değiştirme günlüğü.

9) Olaylar ve bültenlerle iletişim

Her uyarıda - ilgili runbook bir bağlantı.
Her olayda, kullanılan SOP'a bir referans ve işaretlerin bir kontrolü.
RCA'dan sonra - belgeleri CAPA eylemi olarak güncelleyin.
Piyasaya sürülmeden önce - kontrol listesi: geri alma hazırlığı, bozulma bayrakları, sağlayıcı kişileri.

10) Minimum Gerekli Set (MVP Dock Paketi)

Olay Yönetimi ve Eskalasyon Politikası (SEV/P seviyeleri, zamanlamalar).
Standart ve uyarı politikasının izlenmesi (yanma oranı, yeterli çoğunluk).
SOP: serbest bırakma/geri alma (kanarya/mavi-yeşil), veritabanı geçişleri (genişletme/sözleşme).
Runbook: "Yüksek hata oranı", "p99 büyümesi", "Ödeme başarısı düşüşü", "TLS/DNS sorunu".
Dış sağlayıcıların oyun kitabı (ödemeler/KYC/CDN): kişiler, sınırlar, geri dönüşler.
Gizli ve erişim yönetimi politikası.
RCA ve Post-mortem şablonları.
Hizmet Sahipliği Tablosu (RACI) ve gösterge tablosu haritası.

11) Dokümantasyon Kalite Metrikleri (Document SLO)

Kapsam: SOP/Runbook ile kritik yolların %'si.
Tazelik: Belgelerin payı N günden daha yeni (örneğin 90).
Kullanılabilirlik: Olayların %'si tırmandırılmadan çalışma kitabına göre kapatıldı.
Bulunabilirlik: istenen belge için medyan arama süresi (anketlere/günlüklere göre).
Hata oranı: inceleme başına yorum sayısı/100 belge.
Benimseme: Doğru runbook referansı ile uyarıların yüzdesi.
Uyumluluk kanıt oranı: Kanıt ekli görevlerin %'si.

12) Kontrol listeleri

SOP Oluşturma Kontrol Listesi

  • Sahip ve hedef kitle tanımlandı.
  • Başlangıç koşulları ve durma kriterleri vardır.
  • Adımlar tekrarlanabilir, başka bir mühendis tarafından kontrol edilir.
  • Panolara/uyarılara/araçlara yerleşik bağlantılar.
  • Sır yok; Yer tutucular ve bir kasa bağlantısı var.
  • Geri alma ve tırmanmayı açıklar.
  • "Eylem sonrası" kontrol listesi eklendi.
  • Sürüm, tarih, changelog.

İnceleme kontrol listesi

  • Belge taksonomiye karşılık gelir (politikaları ve adımları karıştırmaz).
  • Dil, belirsizlik olmadan basit, zorunludur.
  • "Dry run "/aşamasında test edilen takımlar.
  • Riskler ve kontrol noktaları belirtilmiştir.
  • Dahili/Kısıtlı doğrudur.
  • Linters/doğrulayıcılar CI geçti.

13) Yerelleştirme, sürüm ve kullanılabilirlik

Versiyon: 'MAJOR. MINÖR. PATCH ', MAJOR'un süreç uyumluluğunu bozduğu yer.
Diller: "Kaynak" dili ve çeviri durumunu işaretleyin (güncel/ihtiyaç incelemesi).
Form faktörü: Çağrı üzerine, basılı IC kartları için mobil/gece ekranı.

14) Dock otomasyonu (uygulamadan)

CLI şablonlarından SOP çerçeveleri oluşturma ('doc new sop -service = payments').
Servis etiketlerine göre en son panolara bağlantıları otomatik olarak ekleyin.
Gecikmiş belgeler hatırlatma botları (tazelik SLA).
Denetim için dönem için Kanıt paketini (PDF/ZIP) dışa aktarın.
Olay biletlerini, çözümde kullanılan belgelerin sürümüyle ilişkilendirin.

15) Güvenlik ve uyumluluk

Zorunlu bölümler "Riskler've" Kontrol önlemleri ".
Kanıtları, imzalar/karmalar ile değişmeyen bir arşivde saklamak.
Düzenlemelere bağlanma (örn. bildirim/saklama süreleri), açık uyumluluk sahipleri.

16) Anti-desenler

Sahipler ve güncelleme tarihleri olmadan "Wiki Labirenti".
Politikacılar takımlara karışır - kimse ne yapacağını bulamaz.
Bağlam içermeyen belgeler (SLO yok, gösterge panoları, yükseltmeler).
CLI alternatifleri olmadan sırlı ekran görüntüleri veya "buraya tıklayın" talimatları.
"Bir guru nasıl olduğunu bilir" - sabitleme olmadan kabile bilgisi.
Tek sürüm olarak arşivlenmiş PDF'ler düzenlenmez, aranmaz.

17) Şablonlar (parçalar)

SOP kapağı (örnek)


SOP-ID: OPS-REL-001

18) Günlük işe yerleştirme

Haftalık doc-circles: 1-2 belgenin analizi, güncellenmesi, deneyim alışverişi.
Oyun günleri: Simülasyonlarda SOP/Runbook gerçeklik kontrolü.
Onboarding: Bir dizi zorunlu belge + kısa sınavlar yoluyla yeni başlayanların rotası.
Dock borcu: Önceliklendirme (etki × çaba) ile iyileştirmelerin birikmesi.

19) Alt satır

İşlem dokümantasyonu bir arşiv değil, bir çalışma aracıdır. Kod olarak yönetildiğinde, sahiplere, tazelik ölçümlerine sahip olduğunda ve olaylara, sürümlere ve eğitime gömüldüğünde, kuruluş öngörülebilir hale gelir: daha az hata, daha hızlı tepki, anlaşılır sorumluluk ve denetime hazır olma. Kısaca yazın, düzenli olarak güncelleyin, rutini otomatikleştirin - belgeler zaman ve paradan tasarruf etmeye başlayacaktır.
Contact

Bizimle iletişime geçin

Her türlü soru veya destek için bize ulaşın.Size yardımcı olmaya her zaman hazırız!

Entegrasyona başla

Email — zorunlu. Telegram veya WhatsApp — isteğe bağlı.

Adınız zorunlu değil
Email zorunlu değil
Konu zorunlu değil
Mesaj zorunlu değil
Telegram zorunlu değil
@
Telegram belirtirseniz, Email’e ek olarak oradan da yanıt veririz.
WhatsApp zorunlu değil
Format: +ülke kodu ve numara (örneğin, +90XXXXXXXXX).

Butona tıklayarak veri işlemenize onay vermiş olursunuz.