CTO · DevOps Manager

Hızı yavaşlatmadan kontrolü nasıl eklersiniz? How do you add control without slowing delivery?

Ekibiniz "governance" kelimesini duyduğunda yavaşlama anlıyorsa, bugüne kadar gördüğü yönetişim gerçekten yavaşlatmıştır. If your team hears "governance" and thinks "slower", every version of governance they have met so far did slow them down.

Bugün bu soru nasıl cevaplanıyorHow this question is answered today

Kontrol eklemek pratikte onay adımı eklemek demek. Onay adımı eklemek beklemek demek. Beklemek de takımın hızını düşürmek demek.

In practice, adding control means adding an approval step. Adding an approval step means waiting. Waiting means the team slows down.

Bu denklem doğru olduğu için iki sonuçtan biri oluyor: ya kontrol hiç eklenmiyor, ya da eklendikten sonra acil durumlarda atlanıyor. İkisi de anlaşılabilir.

Because that equation is true, one of two things happens: either the control is never added, or it is added and then skipped whenever something is urgent. Both are understandable.

Sonuçta iş üretime ulaşıyor ama bir kısmı hattın dışından ulaşıyor. Hattın dışı, ölçtüğünüz hiçbir metrikte görünmüyor.

The work still reaches production, but part of it arrives outside the pipeline. What happens outside the pipeline appears in none of the metrics you track.

Bu cevabın maliyetiWhat that answer costs

Hattınızın kapsama oranını bilmiyorsunuz. Üretime giden işin ne kadarı hattan geçiyor, ölçülmüyor.You do not know your pipeline's coverage. How much of the work reaching production actually goes through it is never measured.
Aynı riskteki iki değişiklik, farklı kişilerin elinde farklı muamele görüyor. Bu tutarsızlık kimseye hata olarak görünmüyor.Two changes carrying the same risk get different treatment in different hands. That inconsistency looks like nobody's mistake.
Düşük riskli değişiklikler yüksek riskli olanlarla aynı onay yükünü taşıyor. Sonuçta iki taraf da mutsuz.Low risk changes carry the same approval burden as high risk ones. Both sides end up unhappy.
Bir olaydan sonra "bu neden hattan geçmedi" sorusunun cevabı yeniden inşa ediliyor.After an incident, the answer to "why did this not go through the pipeline" has to be reconstructed.

Yönetişim bunu nasıl değiştirirWhat governance changes

Kontrolü hattın önüne koymak yerine hattın içine koymak mümkün. Ayrım noktası şu: her değişikliğe aynı onay yükünü vermemek.

Control can sit inside the pipeline rather than in front of it. The difference is this: not every change carries the same approval burden.

Riski düşük bir değişiklik hiç beklemez. Riski yüksek olan durur ve bunun sebebi kaydın içinde yazılıdır. Kararı veren kural, kişi değil.

A low risk change waits for nobody. A high risk one stops, and the reason is written into the record. The rule decides, not the person.

Hattın dışından yapılan müdahale de aynı kapsama alınabilir. Bu bir yasak değildir; elle müdahale operasyonel bir gerçektir. Değişen şey, o müdahalenin acil durum veya elle işlem olarak beyan edilmesi ve gerekçesiyle birlikte aynı kayıt modeline girmesidir.

Work performed outside the pipeline can be brought into the same scope. This is not a ban; manual intervention is an operational reality. What changes is that the intervention is declared as an emergency or a manual action and enters the same record model together with its justification.

Bunun sınırını açıkça söyleyelim: platform, hiç beyan edilmemiş bir müdahaleyi kendiliğinden tespit etmez. Kazanç, gece yapılan işin hiçbir yere yazılmaması ile gerekçeli bir kayda dönüşmesi arasındaki farktır.

The limit is worth stating plainly: the platform does not detect an intervention that was never declared. The gain is the difference between night work that lands nowhere and night work that becomes a justified record.

Hız kontrolle takas edilmez; kural hattın içine girer ve hattın dışına çıkan işin de aynı kayıt modelinde yeri olur. Speed is not traded for control; the rule moves inside the pipeline, and work that leaves it has a place in the same record model.