Kendi kendine barındırma için üretim hazır uygulama devri kontrol listesi

Production-ready teslimatı pratikte ne demek

Production-ready teslimat, operasyon ekibinin tahmin yürütmeden uygulamayı çalıştırabilmesi demektir. Bilinen bir sürümü dağıtabilir, sağlıklı olduğunu doğrulayabilir, uyarılara yanıt verebilir ve kötü bir sürüm ya da kesinti durumundan kurtarabilirler. Bu işlerden herhangi biri tek bir geliştiricinin hafızasına bağlıysa, teslimat tamamlanmış sayılmaz.

Teslimatı, şu soruyu yanıtlayan bir paket olarak düşünün: asıl geliştiriciler bir hafta ortadan kaybolsa, operasyonlar sistemi güvenli ve erişilebilir tutabilir mi?

İyi bir paket genellikle uygulamanın ne yaptığını, "sağlıklı" olmanın ne demek olduğunu, sürümlerin nasıl işlediğini (deploy, doğrulama, geri alma), yapılandırmanın nerede olduğunu, gizli bilgilerin nasıl ele alındığını ve nasıl izleneceğini, yedekleneceğini ve olaylara nasıl yanıt verileceğini kapsar.

Aynı zamanda teslimatın neleri kapsamadığı da önemlidir. Teslimat, özellik ekleme, yeniden düzenleme, ekranları yeniden tasarlama veya "sonra temizleme" sözü değildir. Bunlar ayrı projelerdir ve kendi kapsamları vardır.

Tamam dediğinizden önce sahiplik ve yanıt süreleri üzerinde anlaşın. Örneğin: ops uptime sorumluluğunu üstlenir ve deploy gerçekleştirir; ürün ekibi yol haritasından sorumludur; geliştirici ekibi, teslimattan sonra sorular ve düzeltmeler için tanımlı bir destek penceresi sağlar.

Basit bir sistem envanteri oluşturun (nerede ne çalışıyor)

Ops yalnızca görebildiğini sahiplenebilir. Tek sayfalık bir envanter deploylar, olaylar ve denetimler sırasında tahmini engellerini ortadan kaldırır. Düz İngilizce (veya hedef dil) ile açık ve spesifik tutun.

Sistemin her çalışan parçasını ve nerede olduğunu listeleyin: backend API, web uygulaması, arka plan worker'ları, zamanlanmış işler ve mobil uygulamaların nasıl bağlandığı. iOS/Android mağazalar aracılığıyla dağıtılsa bile aynı backend'e bağımlıdırlar, bunu unutmayın.

Uygulamanın çalışması için gerekli üçüncü taraf servisleri dahil edin. PostgreSQL, bir kuyruk, obje depolama veya üçüncü taraf API'ler (ödemeler için Stripe, mesajlaşma, e-posta/SMS, Telegram) kullanıyorsanız, kesin servis adını ve ne için kullanıldığını yazın.

Barındırma denemeye dayanmasın diye ağ gereksinimlerini yakalayın: gereken alan adları (app, api, admin), portlar ve protokoller, TLS sertifikalarını kim yeniler, DNS nerede yönetiliyor ve varsa gelen/giden allowlist'ler.

Son olarak, beklenen yükü gerçek sayılarla yazın: dakikadaki en yüksek istek sayısı, aktif kullanıcılar, tipik yük boyutları, mevcut veritabanı boyutu ve beklenen büyüme. Kabaca aralıklar bile ops'un limit ve uyarıları ayarlamasına yardımcı olur.

AppMaster ile inşa ettiyseniz, üretilen backend, web uygulaması ve entegrasyonları envantere ekleyin ki ops hangi parçaların birlikte dağıtılması gerektiğini bilsin.

Çevre yapılandırmasını paketleyin (gizli bilgileri ifşa etmeden)

Prod yapılandırmaları genellikle sıkıcı kısımda başarısız olur: yalnızca birinin kafasında olan konfigürasyon. Yapılandırmayı bir teslimat çıktısı gibi ele alın. Ops hangi ayarların olduğunu, ortamlar arasında nelerin farklı olduğunu ve bunları nasıl güvenli şekilde değiştireceklerini görebilmelidir.

Öncelikle bugün var olan her ortamı adlandırarak başlayın, geçici olsa bile. Çoğu ekipte dev, staging ve production olur; ayrıca "production-eu" veya "staging-us" gibi kopyalar olabilir. Hangi ortamın sürüm testi, veri göçleri ve olay tatbikatları için kullanıldığını not edin.

Tüm değişken adlarını ve güvenli örnek değerleri (gerçek kimlik bilgileri asla değil) listeleyen tek bir konfigürasyon referansı sağlayın. Yer tutucuları belli edin.

Teslimat paketiniz şunları içermeli:

• Ortamların listesi ve her birinin ne için olduğu
• Konfigürasyon anahtarlarının (env var ya da config dosyası anahtarları) referansı, beklenen türü ve gizli olmayan örnek değeri
• Ortamlar arasındaki bilinen farklar (özellik bayrakları, hız limitleri, cache boyutları, e-posta modu, logging seviyesi)
• Varsayılanlar ve bir anahtar eksikse ne olacağı
• Konfigürasyonun nerede saklandığı ve deploy sırasında nasıl uygulandığı

Basit bir değişiklik süreci ekleyin. Örneğin: değişiklik talebi bir ticket ile, servis sahibinin incelemesi, önce staging'e uygulama, sonra planlı bir pencerede production'a terfi ve hata oranları yükselirse geri alma planı.

AppMaster'dan dışa aktarıp kendi kendinize barındırıyorsanız, aynı kuralı uygulayın: üretilmiş kaynakla birlikte temiz ve belgelenmiş bir konfigürasyon anahtarları seti gönderin ki ops farklı ortamlarda tutarlı çalıştırabilsin.

Gizli bilgiler ve kimlik bilgileri: depolama, döndürme ve erişim

Gizli bilgiler, temiz bir teslimatı hızla bir güvenlik olayına dönüştürmenin en hızlı yoludur. Amaç basit: ops uygulamanın ihtiyaç duyduğu her gizli bilginin ne olduğunu, nerede saklandığını, kimlerin okuyabildiğini ve kesinti olmadan nasıl değiştirileceğini bilmeli.

Ops'un bir dakikada tarayabileceği kısa bir gizli bilgi listesiyle başlayın. Her öğe için neyi açtığını (veritabanı, SMTP, Stripe, JWT imzalama anahtarı), nerede durduğunu (vault, bulut gizli depo, Kubernetes Secret, şifrelenmiş dosya) ve döndürmeden kimin sorumlu olduğunu not edin.

Döndürme adımlarını politika gibi değil, tarif gibi yazın. Kesin sıra, eski gizli bilginin ne kadar süre geçerli kalması gerektiği ve işin başarılı olduğunu gösteren tek kontrolü ekleyin.

Döndürme kontrol listesi (örnek)

Her gizli bilgi için bu deseni kullanın:

• Yeni gizli değer oluşturun ve onaylanmış gizli yöneticiye kaydedin.
• Uygulamanın yeni değeri kullanması için konfigürasyonu deploy edin.
• Doğrulayın: girişler, ödemeler veya API çağrıları başarılı olsun ve hata oranları normal kalsın.
• Eski gizli bilgiyi iptal edin ve artık çalışmadığını doğrulayın.
• Döndürme tarihini, işi yapanı ve bir sonraki tarihin kaydını tutun.

Şifreleme beklentileri konusunda açık olun. Gizli bilgiler gizli depoda dinlenme halinde şifrelenmiş olmalı ve uygulama ile bağımlılıklar arasındaki iletişim TLS ile korunmalıdır. Gizli bilgileri kaynak kontrolde, build artefaktlarında veya paylaşılan dokümanlarda asla tutmayın.

Break-glass erişimini tanımlayın. Bir kesinti normal erişimi engellerse, acil erişimi kim onaylar, ne kadar sürer ve sonrasında ne denetlenmelidir belirtin.

Dağıtım paketi: artefaktlar, sürümler ve geri alma

Ops yalnızca yeniden üretebildiğini sahiplenebilir. İyi bir dağıtım paketi üç soruyu yanıtlamayı kolaylaştırır: tam olarak ne çalışıyor, bunu nasıl tekrar deploy ederiz ve bir şeyler bozulursa nasıl hızlıca geri döneriz?

Bir yapı için açık bir "malzeme listesi" ekleyin. Sadece nerede durduğunu değil, doğrulamanın nasıl yapılacağını yazın:

• Artefakt detayları: container image adı/tag'i (veya binary/paket adı), uygulama sürümü, build tarihi, checksum
• Kaynak referansı: buildde kullanılan release tag veya commit hash, önemli build flag'leri
• Desteklenen hedefler: VM, konteyner (Docker) veya Kubernetes ve hangisinin önerildiği
• Dağıtım adımları: önkoşullar (runtime, veritabanı, depolama), kesin sıra ve tipik deploy süresi
• Veritabanı göçleri: nasıl çalıştırıldıkları (başlangıçta otomatik mi yoksa manuel mi), logların nerede olduğu ve başarının nasıl doğrulanacağı

Küçük, somut bir örnek ekleyin. Örneğin: “v1.8.2'yi dağıtmak için image tag'ini güncelleyin, migrationları çalıştırın, sonra web worker'ları yeniden başlatın. Sağlık kontrolleri 10 dakika içinde başarısız olursa v1.8.1'e geri dönün ve migration işini durdurun.”

Tahmin içermeyen geri alma

Geri alma planı gece 2'de uygulanabilir talimatlar gibi olmalı. Şunları belirtmeli:

• Geri almayı tetikleyen sinyal (hata oranı, başarısız sağlık kontrolü, bozuk giriş)
• Son bilinen iyi sürüm ve nerede saklandığı
• Veritabanı değişikliklerinin geri alınabilir olup olmadığı ve alınamıyorsa ne yapılacağı

Uygulama AppMaster ile oluşturulup kaynak kodu olarak dışa aktarıldıysa, üretilen kod sürümünü, build talimatlarını ve çalışma zamanı beklentilerini ekleyin ki ops aynı sürümü daha sonra yeniden inşa edebilsin.

İzleme ve uyarı: neyi ölçmeli ve ne zaman çağrı yapmalı

Teslimat, ops uygulamanın ne yaptığını görebildiğinde ve kullanıcılar şikayet etmeden önce uyarıldığında tamamlanmış sayılır.

Hangi logların olması gerektiği ve nereye gönderildiğini (dosya, syslog, log platformu) kararlaştırın. Logların zaman senkronize olduğundan ve istek ya da correlation ID içerdiğinden emin olun ki olaylar uçtan uca izlenebilsin.

Genellikle uygulama logları (ana olaylar ve hatalar), hata logları (stack trace'ler ve başarısız job'lar), erişim logları (istekler ve durum kodları), denetim logları (yönetici işlemleri ve dışa aktarımlar) ve altyapı logları (yeniden başlatmalar, node baskısı, disk problemleri) istenir.

Ardından kullanıcı etkisini ve sistem sağlığını yansıtan küçük bir metrik seti tanımlayın. Beş seçilecekse: gecikme (p95/p99), hata oranı, doygunluk (CPU/ram/disk), kuyruk derinliği ve ağ dışı kullanılabilirlik kontrolleri.

Uyarı kuralları net olmalı: ne tetikler, öncelik (page vs ticket), kimin nöbette olduğu ve ne zaman eskalasyon yapılacağı. "İyi" bir dashboard anlık görüntüsü ekleyin ve normalin ne olduğunu (tipik gecikme aralığı, beklenen hata oranı, olağan kuyruk derinliği) kısa bir notla açıklayın. Bu bağlam, gürültülü uyarıları azaltır ve yeni müdahale edenlerin hızlı hareket etmesini sağlar.

Yedeklemeler ve kurtarma: geri dönüşleri tekrarlanabilir yapın

Yedeklemeler "sahip olunan" bir şey değil; gerektiğinde geri yükleyebildiğiniz bir şeydir.

Kapsamı kesin yazın: veritabanı, dosya depolama (yüklemeler, raporlar, faturalar) ve genellikle unutulan parçalar—kodda olmayan konfigürasyon ve korunmuş verileri okumak için gereken şifreleme anahtarları.

Hedefleri açık terimlerle tutun. RPO ne kadar veri kaybedilebileceğini (örneğin 15 dakika) belirtir. RTO ne kadar sürede geri dönülebileceğini (örneğin 1 saat) belirtir. İş birimi ile anlaşılmış sayıları seçin; çünkü bunlar maliyet ve çabayı belirler.

Şunları ekleyin:

• Ne yedekleniyor, nerede saklanıyor ve saklama süresi
• Yedekleri ve geri yüklemeyi kimin çalıştırabileceği ve erişimin nasıl onaylandığı
• Adım adım geri yükleme prosedürü ve doğrulama kontrolleri
• Geri yükleme loglarının nerede olduğu ve "başarı"nın ne olduğu
• Yaygın hata modları (yanlış anahtar, eksik bucket, şema uyuşmazlığı) ve düzeltmeleri

AppMaster ile dışa aktarılmış ve kendi kendine barındırılan bir uygulama varsa PostgreSQL geri yükleme adımlarını, harici depolama bucket'larını ve şifrelenmiş alanlar için kullanılan anahtarları ekleyin.

Bir geri yükleme tatbikatı planlayın. Zamanı, neyin bozulduğunu ve ne değiştirdiğinizi kaydedin ki bir sonraki geri yükleme daha hızlı ve daha az stresli olsun.

Runbook'lar ve on-call: gerçek olayları ops nasıl yönetir

Teslimat, birinin gece 2'de çağrıldığında tahmin yürütmeden sorunu düzeltebildiği zaman gerçek olur. Runbook'lar kabile bilgisini on-call kişinin izleyebileceği adımlara çevirir.

İlk önce beklenen olaylarla başlayın: tam kesinti, yavaş istekler ve deploy'un bir şeyi bozması. Her runbook kısa olsun. Müdahale edenlerin dakikalar içinde sinyal alması için en hızlı kontrolleri en üste koyun.

İyi bir runbook'ta neler olmalı

Yapıyı tutarlı tutun ki baskı altındayken taranabilsin:

• Kullanıcıların gördüğü ve nasıl doğrulanacağı (örnek: hata oranı X%'in üzerinde, ödeme süreci başarısız)
• İlk kontroller (servis durumu, son deploy, bağımlılık sağlığı, disk/CPU, veritabanı bağlantıları)
• Sonraki kontroller (hangi loglar açılmalı, önemli dashboard'lar, son konfigürasyon değişiklikleri, kuyruk derinliği)
• Karar noktaları (ne zaman geri alınır, ne zaman ölçeklendirilir, ne zaman bir özelliği devre dışı bırakılır)
• Eskalasyon (uygulamanın sahibi, altyapının sahibi ve kimin ne zaman çağrılacağı)

Uygulama AppMaster'dan dışa aktarılıp kendi kendine barındırılıyorsa, üretilmiş servislerin nerede çalıştığını, bunları güvenli şekilde nasıl yeniden başlatacağınızı ve her ortam için beklenen konfigürasyon değerlerini ekleyin.

Olay sonrası: doğru bilgileri yakalayın

Kısa bir olay sonrası kontrol listesi tutun. Zaman çizelgesini, son değişiklikleri, tam hata mesajlarını, etkilenen kullanıcıları ve sorunu düzelten eylemi kaydedin. Ardından runbook'u detaylar hâlâ taze iken güncelleyin.

Erişim kontrolü ve izinler: kim ne yapabilir

Ops bir sistemi sahiplenebilirse, kimin neyi değiştirebileceği ve erişimin nasıl takip edildiği açık olmalıdır.

Gerçekten kullandığınız rolleri yazın. Birçok ekip için yeterli olanlar şunlardır:

• Deployer: onaylanmış sürümleri deploy eder ve rollback tetikler
• DB admin: şema değişiklikleri yapar ve yedekleri geri yükler
• Sadece-okuma: dashboard'ları, logları ve konfigürasyonları görüntüler ama düzenlemez
• Incident commander: bir kesinti sırasında acil işlemleri onaylar

"Kapı politikası"nı düz adımlarla belgeleyin: erişimi kim veriyor, nerede veriliyor (SSO, bulut IAM, veritabanı kullanıcıları, CI/CD, admin panelleri), kim iptal ediyor ve offboarding sırasında kaldırıldığını nasıl doğruluyorsunuz.

İnsan olmayan erişimi unutmayın. İşler, entegrasyonlar ve izleme tarafından kullanılan her hizmet hesabını ve token'ı listeleyin; her biri için en az ayrıcalık notu ekleyin (örnek: "sadece X bucket'tan okuyabilir"). AppMaster kaynak kodunu kendi kendine barındırma için dışa aktarıyorsanız, bu kimliklerin hangi env var veya konfigürasyon dosyalarıyla tanımlandığını ekleyin ama gizli değerleri asla yapıştırmayın.

Ayrıca denetim logu beklentilerini belirleyin: nelerin loglanması gerektiği (giriş, deploy, konfigürasyon değişikliği, DB admin işlemleri), kimlerin logları okuyabildiği, saklama süresi, logların nerede tutulduğu ve olay veya inceleme sırasında log talebinin nasıl yapılacağı.

Güvenlik ve uyumluluk temel bilgileri (düz İngilizce/Türkçe)

Güvenlik notları uzman olmayanların da okuyabileceği şekilde yazılmalı ama ops'un harekete geçmesine yetecek kadar spesifik olmalı. Bir sayfalık özet ekleyin: hangi verileri saklıyoruz, nerede duruyor ve kim erişebiliyor?

Veri türleriyle başlayın: müşteri profilleri, destek kayıtları, ödeme meta verileri, dosyalar. PII gibi hassas kategorileri (isimler, e-postalar, telefon numaraları), kimlik bilgileri ve şirketinizin önem verdiği düzenlemeye tabi verileri belirtin. AppMaster'dan dışa aktarılmış kaynak kodu ile kendi kendine barındırıyorsanız, bu verilerin veritabanında nereye düştüğünü ve hangi servislerin okuyabildiğini not edin.

Ardından saklama ve silme kurallarını pratik terimlerle yazın. Ne sakladığınızı, ne kadar süre sakladığınızı ve silmenin nasıl çalıştığını (soft delete vs hard delete, gecikmeli temizlik, yedeklemeler) açıklayın. Hukuki beklemeler veya denetim ihtiyaçları varsa, istisnaları kim onaylar belirtin.

Loglar genellikle veritabanlarından daha fazla sızdırır. Hangi alanların PII içerebileceği (erişim logları, hata logları, analiz olayları) ve bunları nasıl azaltıp maskeleneceği konusunda net olun. Bir alanın asla loglanmaması gerekiyorsa bu kuralı açıkça belirtin.

Onayları açıkça yazın:

• Kimlik doğrulama değişiklikleri için isimlendirilmiş onaylayıcı olsun.
• Ödeme ile ilgili değişiklikler (Stripe anahtarları, webhook uç noktaları, iade mantığı) isimlendirilmiş onay gerektirir.
• Rol ve izin modeli değişiklikleri isimli bir onaylayıcı gerektirir.
• Güvenlik yamaları ve acil değişiklik kuralları yazılı olsun.

Bir ekstra şey ekleyebiliyorsanız, kanıt notu ekleyin: denetim loglarının nerede tutulduğu ve biri kanıt istediğinde nasıl dışa aktarılacağı.

Örnek teslim senaryosu: ops bir haftada sahipleniyor

Ops, küçük bir ürün ekibi tarafından oluşturulmuş bir müşteri portalını alıp yeni kendi kendine barındırılan altyapıya taşıyor. Amaç sadece "çalışması" değil; "ops'un geliştiricileri aramadan çalıştırabilmesi".

Hafta nasıl geçer

Gün 1: Ops, yalnızca teslim paketini kullanarak yeni bir ortamda temiz bir ilk deploy yapar. Uygulama açılır ama giriş başarısız olur çünkü e-posta sağlayıcısı için bir ortam değişkeni eksiktir. Bu, env şablonuna eklenir ve deploy sıfırdan çalışana kadar tekrar edilir.

Gün 2: İlk uyarı kasıtlı olarak tetiklenir. Ops kontrollü bir hata (bir servisi durdurma veya giden e-postayı engelleme) yapar ve doğrular: metrikler sorunu gösterir, uyarılar doğru kanala gider ve mesaj ne yapılacağını söyler.

Gün 3: Ödeme sandbox'ında bir token süresi dolar. Kimlik bilgileri konumu ve döndürme adımları belgelenmiş olduğu için ops tahmin yürütmeden ve gizli bilgileri açığa çıkarmadan değişikliği yapar.

Gün 4: DNS geçişi. Yanlış bir kayıt eski IP'yi gösterir ve portal bazı kullanıcılar için erişilemez görünür. Ops runbook'u kullanarak DNS, TLS ve sağlık kontrollerini doğru sırada doğrular.

Gün 5: İlk yedek geri yükleme testi. Ops temiz bir veritabanına geri yükler ve portalın gerçek verilerle yüklenebildiğini kanıtlar.

1 hafta sonra "tamam" ne demek

Uygulama 7 gün boyunca gizemli düzeltmeler olmadan çalışmış, bir başarılı geri yükleme yapılmış, net uyarılar var ve ops tek başına yapabildiği tekrar edilebilir bir deploy sürecine sahip.

Geç teslimata neden olan yaygın hatalar (gece nöbetlerine yol açan)

Sakin bir teslimatı gece 2 yangınına çevirmenin en hızlı yolu "ops'a her şeyi söyledik" varsayımıyla "ops bunu bizim olmadan çalıştırabilir" demeyi karıştırmaktır.

Kendi kendine barındırma teslimatından sonra sık görülen hata desenleri: gizli bilgiler tablolar veya sohbetlerde paylaşılıyor, rollback geliştiriciye bağımlı, yedekler var ama geri yüklemeler hiç test edilmemiş, uyarılar gün boyu çalıyor çünkü eşikler ayarlanmamış ve ortam detayları (portlar, DNS adları, cron zamanları, bulut izinleri) yalnızca birinin kafasında yaşıyor.

Örnek: AppMaster'dan kaynak kodu dışa aktarır ve ilk deploy çalışır. İki hafta sonra bir konfigürasyon değişikliği girişleri bozar. Eğer gizli bilgiler sohbette paylaşıldıysa ve rollback orijinal geliştiriciye bağlıysa, ops işe geri dönebilmek için saatler harcar.

"Teslimat tamam" demeden önce hızlı kontroller

Bilet kapatmadan önce kısa bir temiz-başlangıç tatbikatı çalıştırın. Teslimat paketini bir ops mühendisine ve temiz bir ortama (yeni VM, yeni Kubernetes namespace veya boş bir bulut projesi) verin. Eğer paketle deploy edip uygulamayı gözlemleyip kurtarabiliyorsa belirli bir sürede (örneğin 2 saat) neredeyse hazırsınız demektir.

Bu kontrolleri kullanın:

• Paketlenmiş artefaktlar, konfig dokümanları ve runbook'lar (rollback dahil) kullanılarak sıfırdan yeniden inşa edip deploy edin.
• Her gizli bilginin kararlaştırılan yerde olduğunu doğrulayın ve döndürme adımlarının yazılı ve test edilmiş olduğunu kontrol edin.
• Dashboard'ları açın ve temel soruları yanıtlayıp yanıtlamadığını doğrulayın: ayakta mı, yavaş mı, hata alıyor mu, kaynakları tükeniyor mu?
• Bir güvenli test uyarısı tetikleyin ki paging yolları, sahipleri ve sessizlik saatleri beklendiği gibi çalışsın.
• Ayrı bir ortama gerçek bir geri yükleme testi yapın, sonra tam adımları ve beklenen sonucu belgeleyin.

Üretilmiş kaynak kodu dışa aktarıyorsanız, ops'un build girdilerini, sürümleri ve release tag'lerin nerede kaydedildiğini bildiğini de doğrulayın ki gelecekteki sürümler tekrarlanabilir olsun.

Sonraki adımlar: sahipliği kesinleştirin ve paketi güncel tutun

Pager'ı taşıyacak kişilerle son bir prova yapın. Bunu bir prova gibi ele alın. Aynı paketi kullanarak deploy, rollback, geri yükleme ve uyarıların çalıştığını kanıtlayın.

Son prova genellikle şunları kapsar: test ortamına ve sonra production'a aynı adımlarla deploy, önceki sürüme geri dönme ve uygulamanın çalıştığını doğrulama, temiz bir ortama yedekten geri yükleme ve basit bir gerçek kontrolü (giriş, kayıt oluşturma, mesaj gönderme) doğrulama, bir güvenli test uyarısı tetikleme ve olay sırasında loglar ile dashboard'ların nerede bulunacağını onaylama.

Sahipliği açıkça belirtin. Her runbook (deploy, olay, geri yükleme) için isimlendirilmiş bir sahip ve her uyarı rotası için (birincil nöbetçi, yedek, mesai dışı davranış) sorumlu atayın. Eğer hiçbir uyarının sahibi yoksa, ya görmezden gelinir ya da yanlış kişiyi uyandırır.

İlk haftadan sonra ops'un ne geliştireceğini gösteren kısa bir Day 2 planı yazın: eşiklerin ayarlanması, maliyet kontrolü, eski artefaktların temizlenmesi ve erişim gözden geçirmesi. Kısa ve zaman kutulu tutun.

AppMaster (appmaster.io) ile inşa ettiyseniz, dışa aktarılan kaynak kodu veya tam dağıtım hedef detaylarını (bulut, bölgeler, build ayarları, gereken servisler) ekleyin ki ops orijinal proje çalışma alanına bağımlı kalmadan uygulamayı çoğaltabilsin. Gereksinimler değiştikçe paket güncellensin diye basit bir ritim belirleyin ki runbook'lar gerçeklikten sapmasın.