İçeriğe geç
Metodoloji · Nasıl Kuruyoruz

Çoğu yazılım canlıya çıktıktan sonra düzeltilir. Biz tam tersini yaparız.

Bir mermer plakasını izlerken, bir hastanın verisini korurken ya da bir otelin doğrudan rezervasyon akışını kurarken; titizlik aynıdır. Bir sistemin nasıl davranması ve nasıl arızalanması gerektiğini, kod yazmadan önce çözeriz. Aşağıdaki her aşama gerçek çıktılar üretir ve bir sonraki aşama başlamadan önce onaydan geçer.

  1. 01 · DISCOVERY.THREAT_MODEL
    Keşif ve Tehdit Modelleme
  2. 02 · ARCHITECTURE.DETERMINISTIC
    Öngörülebilir Sistem Mimarisi
  3. 03 · VERIFICATION.RIGOROUS
    Titiz Doğrulama ve Test
  4. 04 · ORCHESTRATION.GLOBAL
    Küresel Yayılım ve İşletme
01
DISCOVERY.THREAT_MODEL

Keşif ve Tehdit Modelleme

Sistemin nasıl kırılabileceğini ve kimin kırmaya çalışabileceğini, kimse kod yazmadan önce anlayın.

  • Saldırgan gözüyle inceleme
  • Veri sınıflandırma
  • Uyum ön kontrolü

Her çalışmaya, sisteme bir saldırganın gözünden bakarak başlarız. Keşif, somut çıktıları olan gerçek bir iştir: güven sınırlarını çıkarır, verinin nereye aktığını izler ve dayandığımız herhangi bir parça arızalandığında hasarın nereye kadar yayılacağını hesaplarız. Burada verdiğimiz kararlar sonraki mimariyi belirler; önce tasarlayıp güvenliği sonradan eklemeyiz.

Disiplinler
Güven Sınırlarının Haritalanması

Bir saldırganın nereden girebileceğini bulmak için her sürecin, veri deposunun ve veri akışının tek tek incelenmesi.

Arıza Etki Analizi

Bağlı olduğumuz herhangi bir dış veya iç servis çöktüğünde neyin, ne kadar etkileneceğinin ölçülü bir haritası.

Yasal Gereklilik Haritası

Verinin nereye gittiğinin, geçerli kurallara göre sınıflandırılması: KVKK, GDPR ve sektörünüzün gereksinimleri.

Hız ve Güvenilirlik Hedefleri

Mimari başlamadan önce kararlaştırılıp imzalanan hız, kesintisiz çalışma ve veri doğruluğu hedefleri.

Çıktılar
Sistem Tehdit Modeli
STRIDE / LINDDUN
Güven Sınırı Şeması
C4 · L1–L2
Hız ve Güvenilirlik Defteri
İmzalı başlangıç değerleri
02
ARCHITECTURE.DETERMINISTIC

Öngörülebilir Sistem Mimarisi

Yük ve arıza altındaki davranışı sabaha karşı 3'te değil, kâğıt üzerinde belirlenmiş bir sistem tasarlayın.

  • ADR yönetimi
  • Arayüz sözleşmesi incelemesi
  • Arıza senaryolarının önceliklendirilmesi

Mimarinin kendiliğinden oluşup tutmasını ummayız. Her bileşen net değişmez kurallar, sınırlı bir kaynak bütçesi ve tanımlı bir kontrollü bozulma yolu alır. Arayüzler kimse uygulamadan önce kararlaştırılır; veritabanını seçmeden önce veri yapısını modelleriz. Sonuç; arıza modları yazılı ve ölçekleme davranışı hesaplanmış, umut edilmemiş bir tasarımdır.

Disiplinler
Bağlantılarda Önce Anlaşmak

Kimse kurmaya başlamadan önce her parçanın diğerine tam olarak nasıl bağlanacağını kararlaştırır ve sabitleriz.

Net Veri Sahipliği

Sistemin her parçası için hangi veriye kimin sahip olduğunu, verinin nasıl doğru kaldığını ve nasıl bölündüğünü tanımlarız.

Planlı Yedekler

Dayandığı bir parça arızalanırsa, sistem çökmek yerine planlı bir yedeğe geçer ve çalışmayı sürdürür.

Taşıyabileceği Yük

Sistemin ne kadar trafiği, biraz pay bırakarak kaldırabildiğini hesaplar ve kararlaştırdığımız hedeflere göre denetleriz.

Çıktılar
Mimari Karar Kayıtları
Kalıcı kayıt defteri
Arayüz Anlaşmaları
OpenAPI / AsyncAPI
Yük ve Ölçekleme Modeli
Sayısal
03
VERIFICATION.RIGOROUS

Titiz Doğrulama ve Test

Sistemin çalıştığını iddia etmeyin. Kurabildiğiniz en kötü koşullarda gösterin.

  • Onay noktası zorunlu
  • Tehdit modeline göre kapsam
  • İmzalı sürümler

Doğrulamayı güvence değil, kanıt olarak görürüz. Test hattı; özellik tabanlı ve sözleşme testlerini çalıştırır, gerçekçi yükü yeniden oynatır ve neyin dayandığını görmek için bilerek arıza yaratır. Kapsamı; kulağa hoş gelen bir yüzdeye göre değil, tehdit modeline ve kararlaştırdığımız gereksinimlere göre ölçeriz.

Disiplinler
Tasarıma Göre Test

Tasarım sırasında koyduğumuz kuralların, makinenin her değişiklikte otomatik denetlediği testlere dönüştürülmesi.

Tekrarlanabilir Yük Testi

Sistemin ne kadar yükü kaldırabildiğini görmek için, denetimli koşullarda uygulanan tekrarlanabilir ve gerçekçi trafik.

Kasıtlı Arıza Tatbikatları

Planladığımız her yedeğin gerçekten çalıştığını kanıtlamak için parçaları otomatik ve sık sık bilerek bozarız.

Tedarik Zinciri Doğrulaması

Kullandığımız her dış bileşenin tam listesi, her birinin kaynak kanıtı ve kurcalanamayacak şekilde imzalanmış sürümler.

Çıktılar
Doğrulama Kanıt Paketi
Sürüm başına
Bileşen Listesi ve Kaynak Kanıtı
SLSA uyumlu
Dayanıklılık Tatbikat Raporu
Arıza matrisi
04
ORCHESTRATION.GLOBAL

Küresel Yayılım ve İşletme

Sistemi bölgelere sorunsuz yayın: kontrollü sürümler, gerçek görünürlük ve prova edilmiş bir kurtarma planı.

  • SLO kontrolü
  • Veri konumu zorunluluğu
  • Kurtarma provası

Teslim, yayına almakla bitmez. Sistemi bölge bölge, geri alınabilir ve kontrollü sürümlerle yayar, veriyi ait olduğu sınırlar içinde tutar ve trafik gelmeden önce her şeyi izlemeye alırız. Kurtarma hedefleri temenni değildir; prova edilir, kılavuzlar gerçekten çalışır ve bir şey ters gittiğinde tepkimiz bilerek sıkıcıdır.

Disiplinler
Kademeli, Geri Alınabilir Sürüm

Sürümü bölge bölge, küçük adımlarla yayınlar, kararlaştırılan kalite hedeflerini izler ve bozulurlarsa otomatik geri alırız.

Verinin Doğru Ülkede Tutulması

Veri ve trafik, ait olduğu ülkeye sabitlenir; bunu platformun kendisi zorunlu kılar.

Uçtan Uca İzleme

Sistemin tamamında eksiksiz izleme; sistemin nasıl davranması gerektiğine dair koyduğumuz kurallara göre denetlenir.

Prova Edilmiş Kurtarma

Gerçekten prova ettiğimiz kurtarma süresi hedefleri; adım adım, gerçekten çalışan kılavuzlarla desteklenir.

Çıktılar
Küresel Yayılım Planı
Bölge matrisi
İzleme Altyapısı
SLO kataloğu
Felaket Kurtarma Kılavuzu
Çalıştırılabilir