Neden her eylem bir makbuz bırakmalı

Çoğu yazılım neyin değiştiğini hatırlar. Bir değişikliğe neden izin verildiğini, ona kimin ya da neyin karar verdiğini ve kararın hangi kanıta dayandığını hatırlayan yazılım ise çok daha azdır. Güven, sessizce işte bu boşlukta aşınır. Bir operasyon ekibi genellikle “şu anki durum nedir” sorusunu yanıtlayabilir; ama çoğu zaman “buraya nasıl geldiğimizi bana göster ve buna iznimiz olduğunu kanıtla” sorusunu yanıtlayamaz.

Threada, ikinci sorunun her zaman yanıtlanabilir olması için inşa edilmiştir. Yönetilen her eylem bir makbuz bırakır.

Bir makbuz gerçekte neleri içerir

Makbuz bir günlük satırı değildir. Bir günlük satırı “bir şey oldu” der. Bir makbuz ise bir kararı daha sonra yeniden kurmaya ve savunmaya yetecek kadarını söyler. Threada’da, yönetilen bir eylem şunları kaydeder:

• Aktörü. Bir insan operatör ya da bir yapay zeka katılımcısı, ayrı aktör olayları olarak kaydedilir. Bir ajanın onayı asla bir insanınki gibi görünmez.
• Girdileri. WorkItem’i, ondan çıkarılan varlıkları, talep edenin kimliğini ve talebin geldiği kaynak kanalı.
• Kanıtı. Alıntıları, geri getirme izini ve — bağlam yetersiz olduğunda — açık geri çekilme nedenini. Alıntılar ya da kaydedilmiş bir geri çekilme nedeni olmadan Work oluşturulamaz.
• Politikayı. Hangi politika setinin, hangi sürümde etkin olduğunu ve bunun tüm kiracıya mı yoksa daraltılmış bir pack’e, iş akışına, kanala ya da talep eden grubuna mı uygulandığını.
• Sonucu. Eylemin önerilmiş, onaylanmış, reddedilmiş, yürütülmüş, başarılı ya da başarısız mı olduğunu — dokunduğu dış kayda geri bağlantısıyla birlikte.

Bu alanları birlikte okuyun, tek bir adımın savunulabilir bir anlatısına sahip olursunuz. Onları bir WorkItem’in yaşam döngüsü boyunca okuyun, onun tam geçmişine sahip olursunuz.

Sonradan eklenen bir özellik değil, varsayılan olarak denetlenebilirlik

Çoğu sistemde gelen ayartma, denetimi sonraya bırakmaktır: özelliği yayınla, sonra bir müşteri SOC 2 kanıtı istediğinde ya da bir düzenleyici kapıya dayandığında onu günlüklemeyle sar. Bu sıralama tersinedir. Sonradan eklenen denetim her zaman eksiktir, çünkü sistemden, kararın verildiği anda bağlamı taşıması hiçbir zaman istenmemiştir.

Threada bu sıralamayı tersine çevirir. Çalışma zamanı her anlamlı geçişte yapılandırılmış olaylar yayar — work_item_created, approval_requested, approval_decided, action_proposed, action_executed, fallback_triggered — çünkü işi yapma eylemi, onu kaydeden eylemin ta kendisidir. Ayrı bir “denetimi aç” adımı yoktur, çünkü işin kayıt dışı gerçekleştiği hiçbir an yoktur.

Modelin kayıtlar-ve-makbuzlar olduğunu söylerken kastettiğimiz budur. Kayıt, ürettiğiniz bir rapor değildir; işi doğru yapmanın geride bıraktığı tortudur.

Makbuzlar ekiplerin çalışma biçimini neden değiştirir

Bir makbuz, çeyrek sonunda denetçiye yararlıdır. Ama daha sessiz değeri, sıradan bir salı gününün ortasındaki operatöre yöneliktir.

Her eylem kendi kanıtını ve politika temelini taşıdığında, üç şey kolaylaşır:

1. İnceleme hızlı ve dürüst hale gelir. Bir onaylayanın bağlamı hafızasından yeniden kurması ya da özgün talebi öğrenmek için talep edenin peşine düşmesi gerekmez. Kanıt eylemin yanı başında durur. Güven, geri alınabilirlik ve açıklık karar noktasında görünürdür; böylece inceleyenler yalnızca hız için değil, incelenebilirlik için en iyilemeye yönelir.
2. Geri alma güvenli hale gelir. Makbuz politika sürümünü ve girdileri adlandırdığı için, bir eylemi geri sarmak bir arkeoloji projesi değil, tanımlı bir işlemdir. Neyi geri aldığınızı ve neden yapıldığını bilirsiniz.
3. Hesap verebilirlik düşmanca olmaktan çıkar. Kayıt kendiliğinden oluştuğunda, “bunu kim onayladı” bir suçlama değildir — yalnızca bir alandır. Kurucu, onaylayan ve yönetişim rolleri arasındaki görevler ayrılığı uygulanır ve görünürdür; böylece hesap verebilirlik sorusu, herhangi biri sormak zorunda kalmadan önce yanıtlanmış olur.

Yüksek riskli iş insanın elinde, kayıt üzerinde kalır

Makbuzlar her şeyin otomatik olduğu anlamına gelmez. Her şeyin hesabının verilebilir olduğu anlamına gelir. Yüksek riskli otomasyonlar açık bir döngüde-insan ilerleyişini izler — önerildi, ardından onaylandı, ardından yürütülüyor — ve yalnızca bir politikanın açıkça izin verdiği yerde otomatik yürütülür. Makbuz, belirli bir eylemin bu yollardan hangisini izlediğini kaydeder. Otomasyon ve onay birbiriyle gerilim içinde değildir; ikisi de yalnızca iz bırakan adımlardır.

Sonuç, bir denetçiye ve yeni bir operatöre aynı güvenle teslim edebileceğiniz bir sistemdir. Denetçi, kontrollerin tuttuğunu görür. Operatör, son kişinin önündeki vakayı nasıl ele aldığını görür. İkisi de aynı makbuzları okumaktadır.

Threada’nın altında yatan bahis işte budur: bir karara neden izin verildiğini yakalamanın en ucuz zamanı, onu verdiğiniz andır; ve kayıt dışında hiç çalışmayan bir ekip, ikinci soruyu her zaman yanıtlayabilen bir ekiptir.