Fly.io’nun Postgres kümesi 3 gündür kapalı ve buna dair hiçbir haber yok
(community.fly.io)- Temmuz 2023’te Fly.io host’unda yapılan acil bakım (emergency maintenance) sırasında, birden fazla kullanıcının makinelerinin "stopped" ve zombi durumda takılı kalıp yeniden başlatma, kaldırma ve yeniden dağıtım işlemlerinin tamamının imkânsız hale geldiği bir kesinti vakası
- Dashboard’da yalnızca "Service Interruption" banner’ı görünüyor; status page’de ilgili bilgi olmadığı için neden ve kurtarma ETA’sı anlaşılamıyor
- fly machine komutlarının "could not get machine" hatasıyla başarısız olması ve machine list’te oluşturulma tarihinin "1970-01-01" olarak görünmesi gibi anormal veriler tespit edildi
- Bazıları fly scale ile yeni VM başlatarak geçici olarak toparlandı, ancak arızalı VM silinemediği için ücretlendirmenin sürmesi endişesi var
- 12–15 saatten uzun süre resmi yanıt veya durum güncellemesi olmaması platform güvenilirliğinin düşmesine yol açtı
Kesintinin başlaması ve ilk belirtiler
- Sabah uygulamanın health check’leri başarısız olmaya başladı ve makinenin "stopped" durumda olduğu görüldü
- Dashboard’da yalnızca "We are performing emergency maintenance on a host some of your apps instances are running on" mesajını içeren Service Interruption banner’ı gösterildi; bunun dışında bilgi yoktu
- Status page’de bu kesinti gösterilmediği için çözüm süreci veya ETA bulunamadı
- Takılan makine instance’ını yeniden başlatmaya veya kaldırmaya çalışınca timeout oluştu
- Yeniden dağıtım sırasında unmanaged machine ile ilgili hata oluştu
fly deployyalnızca metadata’sındafly_platform_version=v2bulunan makineleri güncellediği için, her makineyifly machine update --metadata fly_platform_version=v2 <machine id>ile tek tek elle güncellemek gerekiyor
Zombi makine durumu ve geçici çözüm
- Bazı makineler "zombie mode" durumuna girerek tüm fly machine komutlarına "Error: could not get machine" yanıtını verdi
- fly scale ile ek VM tahsis edilerek uygulama erişilebilirliği geri getirildi, ancak arızalı VM belirsiz durumda kaldı ve kaldırılamadı ya da hesap silinemedi
fly machine list, oluşturulma tarihi olarak "1970-01-01T00:00:00Z" gibi hatalı veriler gösterdi- Başka bir kullanıcı da aynı şekilde scale up yapıp yeni makine oluşturarak sorunu aştı, ancak asıl makine "connection refused" hatası nedeniyle kaldırılamadı
- Temizlenmeyen zombi VM’ler ve ek oluşturulan VM’lerin tamamı için ücret yansıtılmasından endişe edildi
- Staging ortamı da aynı durumdaydı
Veritabanı container’larına etkisi
- Bir kullanıcı yaklaşık 14 saat önce aynı sorunu yaşamaya başladı; hedef veritabanı container’ı olduğu için yalnızca scale up yapmakla kurtarma mümkün değildi
- Ücretli plan kullanmasına rağmen birkaç saat önce support’a e-posta attı, ancak yanıt alamadı
- İlgili uygulama syd bölgesinde barındırıldığı için, oradaki bir veya iki host’ta sorun olabileceği belirtildi
Geniş etki ve geçici kurtarma
- Düne kadar uygulama + Postgres (staging ve production) olmak üzere 4 makine çalışıyordu; ancak veritabanlarından ikisi dahil 3’ü hâlâ kapalı
- Söz konusu uygulama şirketin harici API uygulaması olduğu için tüm entegrasyonlar durdu
- Operasyonu sürdürmek için Fly üzerinde yeni bir proje oluşturup instance’lar başlatıldı; ortam değişkenleri ve ayarları geriye dönük doldurmak birkaç saat sürdü
- İstemeden de olsa DR (felaket kurtarma) yeteneği testi haline geldi
- db makinesinden verileri almanın bir yolu yoktu; ancak ana production db olmadığı için gereken içerikler tersine mühendislikle kurtarıldı
Platform güvenilirliğine dair endişeler
- 12 saat geçmesine rağmen resmi yanıt olmamasına şaşkınlık dile getirildi
- Aynı sorunu ikinci kez yaşadıkları; hizmet kapalı olsa bile Fly’ın normal raporladığı, bilgi ve müdahale olmadığı için beklemekten başka çare kalmadığı belirtildi
- Heroku ile karşılaştırma: Host kararsız olduğunda dyno otomatik olarak taşındığı için bu tür endişeler yaşanmıyordu
- Küçük, standart bir Rails + Postgres uygulamasında bile ortaya çıkan bir sorun olduğu; daha karmaşık bir uygulamada müdahalenin çok daha zor olacağı endişesi dile getirildi
- Bu tür sorunların platforma duyulan güveni tamamen yok ettiği ifade edildi
1 yorum
Hacker News yorumları
Fly destek başlığına yanıt bıraktı: forumu düzenli olarak kontrol ettiklerini ancak bu gönderiyi gözden kaçırdıklarını ve
sydbölgesindeki tek bir host arızasının uzun sürdüğünü açıkladıHost yeniden başladıktan sonra normale dönemedi ve servis keşfine de bağlanamadığı için manuel kurtarma gerekti
Birden fazla instance ile çalışan uygulamalarda yalnızca bazı instance'lar etkilendi, ancak tek instance'lı uygulamalar kesinti boyunca erişilemez durumdaydı; Fly bu yüzden çoklu instance yapılandırmasını güçlü biçimde tavsiye ediyor
Genel/bölgesel kesintileri status.fly.io'da yayımladıklarını, tek host sorunlarını ise gösterge panelindeki durum sekmesinde gösterdiklerini, ancak bu olaydaki gibi uzun süren tek host arızalarında iletişim yöntemini yeniden gözden geçirdiklerini söyledi
https://community.fly.io/t/service-interruption-cant-destroy...
Yeniden başlatmayla da düzelmedi; eski bir yedeği RDS'e geri yükledim ve taşınmakla doğru yaptığımı düşündüm
Üstelik bu tek bir kullanıcı container'ı değil de yönetilen bir PostgreSQL hizmeti gibi görünüyor; dolayısıyla host arızasına karşı dayanıklılık beklemek daha da makul
Aylık $5~10 ödeyebilirim ama 3 günlük kesinti istemeyen bir yan proje için bunu kullanmayı düşünmem
[1] https://fly.io/docs/about/support/
Kesinti birkaç saat sürdüyse, Ansible ya da başka bir şeyle yeni bir makine ayağa kaldırmaları gerektiğini düşünüyorum. İster donanımda ister AWS/GCP sanal makinelerinde olsun, bu yapılabilirdi
Fly, bu sorunu örtbas etmeye çalışıyormuş gibi başlığı[1] giriş yapmamış kişiler için gizli hâle getirdi
Başlıkta, hizmet çökmüş olmasına rağmen Fly durumunun normal göründüğü, bilgi verilmediği ve beklemekten başka yapılacak bir şey olmadığına dair örnekler vardı
Bir başka kullanıcı da uygulama ile staging/production PostgreSQL dâhil dört makineden üçünün hâlâ kapalı olduğunu, dış API uygulamasının bozulduğunu ve tüm entegrasyonların dağıldığını söyledi
Yeni bir Fly projesi oluşturup geçici instance'lar ayağa kaldırmanın saatler sürdüğünü, DB makinesinden veri almanın bir yolunu bulamadığını anlattı
Kurum durum sayfasının “kesinti yok” demesine rağmen aynı sayfada uygulamanın bakımda ve erişilemez olarak görünmesinin hakaret gibi hissettirdiğini söyleyenler de oldu
17 saat boyunca durum sayfasında neredeyse hiç güncelleme ya da bildirim olmadığını, yalnızca Better Stack uyarıları aldığını yazan bir yorum da vardı
Başlığın tam yedeği: https://pastebin.com/ebmCSZkC
Fly CEO'suna gönderilen tweet: https://twitter.com/SouthPawNZ/status/1682181533673857024
[1] https://community.fly.io/t/service-interruption-cant-destroy...
Fly ile ilgili en kötü şey, bir şeyler ters gittiğinde tek bir şeyin değil, aynı anda birden fazla şeyin bozulması ve durum sayfasının tamamen yeşil görünmesi.
Tepki de genelde ya sessizlik oluyor ya da “Cuma günü deploy edersen böyle olur” gibi fazlasıyla hafif bir tavır.
Ürün havalı görünüyor ama benim kullandığım barındırma hizmetleri içinde en istikrarsız olanın şık bir paketlenmiş hâli gibi hissettiriyor.
İnsanların işini her hafta bozup hafta sonu gecelerini toparlamaya harcattıktan sonra bunu “daha iyi yapabilirdik” diyerek geçiştiremezsiniz. Bu, istisnalar için bir mazeret olabilir ama tekrarlanan bir örüntü için geçerli değil.
Bu HN başlığında çok gürültü var ama bence özeti şu: çalışanlar müşteriler fark etmeden önce sorunu görmüş gibiydi, ücretli destek için e-posta gönderildikten sonra bile yanıt almak saatler sürdü ve çöken host için güncelleme ancak yaklaşık 20 saat sonra geldi.
Etkilenen kullanıcılara host arızası ya da kurtarma yöntemi düzgün şekilde bildirilmedi; dashboard acil bakımı gösterirken durum sayfası her şeyi normal gösteriyordu.
Plan ve mimari gereği böyle kesintilerin beklenen ve yaygın bir şey olduğunu anlıyorum ama iletişim bu kadar kötüyse müşteri kaybedersiniz.
Diğer sağlayıcılarda olduğu gibi üzerinde bulunduğum host biraz bile tuhaf davranınca bana e-posta gönderilse, en azından uygulamam için hemen bir şeyler yapabilirim.
Yine de insanların kendi durumlarının bu olduğunu yeterince bilip bilmediği tartışmalı.
Tek bir belirli sunucuda alışılmadık derecede uzun bir kesinti yaşandı ve bunların birleşimi birçok kişinin açıklamasız uzun süreli kesinti yaşamasına yol açtı.
Dashboard bölge/hizmet kesintilerini gösteriyor ama tekil sunucu kesintilerini göstermiyor; insanlar bunu bilmediği için durumu yalan gibi algıladı.
Discourse etiket ayarlarındaki garip davranış da sorunu gizlemeye çalışıyorlarmış gibi görünmesine neden oldu.
Özetle, şanssızlık vardı, müşteri yönetimi açısından süreçler kötüydü ve dokümantasyon da yer yer yetersizdi; ama bana göre yangından çok dumanın olduğu bir olaydı.
Zaman çizelgesi UTC ile şöyleydi: 2023-07-17 16:19 host düştü, 16:49 kişiselleştirilmiş durum sayfası yayımlandı, 2023-07-19 15:00 host geri geldi, 15:17 durum sayfası çözüldü olarak işaretlendi.
[1] https://community.fly.io/t/new-status-page/11398
Fly.io, Heroku klonu olmak istemedi ama pazarlaması ve iyi cilalanmış kullanıcı deneyimi yüzünden sonunda öyle göründü.
Sonuç olarak, tek bir host arızasında bile markaya ciddi zarar verebilecek Heroku tarzı bir kullanıcı kitlesine de hitap etmek zorunda kaldı.
Eğlencesine yapılan kişisel bir projeydi, o yüzden sorun değildi ama daha ciddi bir kullanım için ne kadar uygun olur emin değilim.
Ayrıca 20 saatlik kesintiyi “beklenen ve normal” diye tanımlayacak kadar çok bulut sağlayıcısı olduğuna inanmak da zor.
Ne yazık ki Fly.io ile ilgili HN başlıklarında epey pasif-agresiflik hissini hep aldım.
Fly.io'yu gerçekten sevmek istedim. Kurulum ve kullanım çok kolay ama dürüst olmak gerekirse mission-critical uygulamaları bu hizmetin üstüne koymamanız gerektiğini düşünüyorum.
Sonunda her şeyi AWS'ye taşıdım; aslında bunu hiç yapmak istemiyordum.
Makineler sık sık çalışmıyordu, rastgele arızalar oluyordu, build'ler başarısız oluyordu ve destek için daha yüksek bir katmana ödeme yapmama rağmen destek yavaş yanıt veriyor ve soruları düzgün okumuyordu.
Sidecar ekleyemiyorsunuz, harici izleme araçlarıyla entegrasyon zor ve dokümantasyon mutlu yol için fena değil ama edge case'lerde çok yetersizdi.
Hobi projeleri için uygun ve şu anda da kişisel projelerimin çoğunu hâlâ orada tutuyorum ama şirket altyapısında zaman ve hayal kırıklığı maliyeti fazla büyüdüğü için taşımak zorunda kaldım.
Heroku'nun zihinsel halefi gibi duyulduğu için beklentim yüksekti ama henüz o seviyede olduğunu düşünmüyorum.
Önceki hafta build oluyordu, lokalde de iyi çalışıyordu ve daha sonra Fly'da da yeniden çalıştı ama nedenine dair hiçbir açıklama ve destekten hiçbir yanıt gelmedi; tam anlamıyla anlamsız bir kesintiydi.
Ücretsiz katman çok cömert; faturalandırma sınırının altında bile epey şey yapılabiliyor ama benim boş zamanım az ve o zamanda sadece projemi build etmek istiyorum.
Üstelik bu sadece Node ile build edilen küçük bir statik siteydi.
Aracın kendisi harika, o yüzden altyapıyı istikrarlı hâle getirirlerse tekrar denemek isterim.
Aynı emekle bu bilgiyi dokümantasyona koyamıyorlarsa dokümantasyon pipeline'larının ne kadar kötü olduğunu düşünmek istemiyorum.
Kullanıma ilişkin forum sorularına verilecek yanıt, “dokümanda var; yoksa az önce ekledim” ve “karıştırdıysak haber verin, dokümanı güncelleyelim” olmalı.
Bizzat
fly logsiçine girip proxy'nin sunucuya ulaşamadığını görmem gerekti ve bunu düzeltmek için yapabileceğim hiçbir şey yoktu.Saatler sonra foruma bir sorun yazdım ama ne yanıt geldi ne de okunduğuna dair bir iz vardı; sonra çok geçmeden sihirli şekilde düzeldi.
Başarılı olmalarını diliyorum ama bu iletişim eksikliği ve hiçbir şey yapamama hissi yüzünden bir süre fly.io kullanmayacağım.
Çok tatmin edici bir yanıt olmayacak ama kişisel olarak söyleyebileceğim en fazla şu: topluluk sitemizde bu başlığın neden listeden çıkarıldığını gerçekten bilmiyorum
Yönetici arayüzüne bakıyorum; gönderinin yanında küçük bir kilit var ama “unlist story” seçeneği hâlâ tıklanabilir durumda
Söyleyebileceğim en iyi şey, bu başlığı gizlemeye yönelik yukarıdan bir talimat geldiğinden oldukça emin olmadığım. Site açık ve herkes hesap oluşturup başlığı görebilir
Hakkımızda ne derseniz deyin ama böyle şeyleri gizlemek bizim zayıf yanlarımızdan biri değil
Sydney sunucu sorunu hakkında henüz yeterince bilgim yok; bu yüzden orada instance çalıştıran kişilere yardımcı olacak bir yanıt veremiyorum. Dışarıdan yeni döndüm ve ancak şimdi anlamaya başlıyorum
Az önce fark ettim ki app-not-working kategorisindeki tüm gönderiler “private” gibi görünüyor; muhtemelen bu bir kategori ayarı. Buradaki private, görmek için Discourse hesabıyla kayıt olmanız gerektiği anlamına geliyor
Bu yanıtın tonu ve fly.io’nun diğer iletişimleri, fly.io hakkındaki genel kanaat düşünüldüğünde bu unsurlarda eksik olduklarına işaret ediyor
60’tan fazla çalışanınız varken sorunlar bu kadar fazlaysa, bu insani ve samimi bir tondan çok ölçeklenemeyen bir işin belirtisi gibi görünüyor
Büyüyen bir B2B işinin başarılı olması için süreçler ve denetim gibi şeyler gerekir; diğer yanıtlara bakınca sanki bunları istemiyormuşsunuz gibi görünüyor, bu da iyi bir işaret değil
Bir kez bozulursa olaydır, iki kez bozulursa şanssızlıktır ama üç kez bozulursa süreç bozulmuştur. Buradaki yorumlara bakılırsa Fly.io’da bu üçten çok daha sık oluyor gibi
Kesintinin kendisi yüzünden değil, destek almanın günler sürebilmesi yüzünden
Bir dahaki sefere desteğin daha iyi olacağına dair topluluğa ne tür bir güvence verebilirsiniz?
https://changelog.com sitesini Nisan 2022’den beri Fly.io üzerinde çalıştırıyoruz ve mevcut mimari https://github.com/thechangelog/changelog.com/blob/master/IN... adresinde
15 ay boyunca Fly.io üzerinde bir Phoenix + PostgreSQL uygulamasıyla 100 milyondan fazla isteği işledik ama şikâyet edecek pek bir şey bulmak zor
Birkaç deployment başarısız oldu ve pipeline’ı yeniden çalıştırarak düzelttik; ayrıca 2023 Temmuz başında Frankfurt’ta 9 bin istek 10 saniye boyunca 503 döndürdü ve machine deneyi sırasında silinmeyen bir volume ertesi gün kayboldu
Kaizen podcast’inde Fly.io deneyimimizden sık sık bahsediyoruz: https://changelog.com/topic/kaizen
Taşınmayı duyurduğumuz bölüm: https://changelog.com/shipit/50
İlgili PR: https://github.com/thechangelog/changelog.com/pull/407
apps v1(Nomad)’den apps v2(flyd)’ye geçiş planından da yakın zamanda söz ettik: https://changelog.com/friends/2#transcript-138
Pek çok kişinin iyi bir deneyim yaşamamış olmasına üzüldüm ama Fly.io’nun gelişmeye devam edeceğini düşünüyorum. Umarım bir gün bu zor dönem iyi bir hikâyeye dönüşür
Umut veren bir yazı: https://community.fly.io/t/reliability-its-not-great/11253
fly.io’yu gerçekten seviyorum ve başarılı olmasını istiyorum. Zor bir iş yapıyorlar, dolayısıyla bir şeylerin bozulması olabilir
Ama iletişim eksikliği hayal kırıklığı yaratıyor; özellikle de CEO’nun mart ayında toplulukta yayımladığı büyük güvenilirlik yazısında bizzat düzeltmek istediklerini söylediği konulardan biri olduğu için
https://community.fly.io/t/reliability-its-not-great/11253#s...
Etkilenen kullanıcıların dashboard’unda tek bir host arızasını gösteriyor, platform/bölge sorunlarını da durum sayfasına yansıtıyor olsak da, ilettiğimiz durumla gerçek kullanıcı deneyiminin örtüşmediği net bir ara alan var
Son dönemde kapasite sorunlarını önlemek için çok fazla donanım ekledik ve beklendiği gibi genel kesinti olasılığı düştü ama donanım kaynaklı arıza sayısı arttı
Kullanıcıların bu tür sorunlardan kaçınmasına yardımcı olma, toparlanma hızını artırma ve etkilendiklerinde onları daha iyi bilgilendirme konusunda daha fazlasını yapabiliriz
İletişimde hata yapsak bile bu tür geri bildirimleri dinliyoruz
Daha büyük tehlike işareti, Fly'ın arızalı bir sunucudaki iş yükünü çalışan bir sunucuya hızla taşıyacak otomatik bir yönteme sahip görünmemesi.
Konteynerler ve orkestratörler bağlanabilir/ayrılabilir veri volume'ü kavramını soyutlamış olsa da durum böyle.
Elbette bunu sunmak büyük bir teknik yatırım gerektirir ve büyük üç bulutta depolamanın pahalı olmasının nedenlerinden birinin de bu olduğunu düşünüyorum. Yine de veri kalıcılığı hizmeti sunuyorsanız, bu mutlaka sahip olmanız gereken bir yetkinlik.
Fly'ın sunmak istediği şey ile pazarın beklediği şey arasında bir uyumsuzluk var.
Fly, uygulamaların birden çok veri merkezinde çalışmasını sağlayan bir yenilik istiyordu, ancak düzgün bir veri kalıcılığı hizmeti olmadan bu özellik çoğu kişi için kullanışlı değil.
Görünüşe göre kalıcılık sorununu SQLite replikasyonu ile çözmeye çalışıyorlar, ama bu durumda çoğu geliştiricinin Fly platformuna uyacak şekilde uygulama geliştirme biçimini değiştirmesi gerekiyor.
Fly, kararlı ve ucuz bir Heroku alternatifi mi olacağına, yoksa dünya çapındaki kullanıcılara en iyi performansı veren kendine özgü bir uygulama geliştirme yaklaşımı mı sunacağına karar vermeli.
App Engine ilginç bir örnek. Zamanının ötesindeydi ve çok yüksek trafiğe kadar ölçeklenebilen bir geliştirme yaklaşımı öneriyordu, ama insanlar buna uyum sağlamak için geliştirme biçimlerini değiştirmek istemedi.
Şu an sanki bir yangını söndürür söndürmez bir başkası çıkıyormuş gibi telaşla koşturuyorlar; bu yüzden teknik yol haritasına güven vermiyor.
Fly.io'yu “sonra tekrar bakılacaklar” listesine koyanların üzerinden zaten yaklaşık iki yıl geçmedi mi?
İnsanlar sizi istikrarsız olarak algılamaya başladığında itibarı toparlamak gerçekten çok zor, özellikle de BT alanında.
Veri kalıcılığı, 24 saatlik ya da elle oluşturulan LVM snapshot'larının S3'e aktarılması şeklinde sağlanıyor.
Bence kalıcı iş yükleri çalıştırılacak bir yer kesinlikle değil. Orada PostgreSQL çalıştırıyorsanız, veriyi yeni bir instance'a hot load etmeye veya yedekten geri yüklemeye hazır olmanız gerekir.
Aynı nedenle HN'de uzun zamandır Fly kullanmamanızı söylüyordum: https://news.ycombinator.com/item?id=31394179
Hesabımın silinmesini talep ettikten sonra, hiçbir iletişim olmadan hesabım bir tür shadow ban durumuna alındı.
E-posta da attım ama bugüne kadar hiç yanıt almadım; sonrasında her şeyi Railway uygulamalarına ve Google Cloud Run'a taşıdım.
Zararsız bir soru sordu diye bir şirket neden shadow ban uygulasın ki?
İlginç olan, Fly.io'da tarihin tekerrür ettiği hissini vermesi. İlk kez Heroku ile karşılaştığım döneme benziyor.
Eski Fly.io, Heroku ilk çıktığında olduğu gibi taze ve heyecan vericiydi; sadeliğine ve kullanım kolaylığına hayran kalmıştım.
Ama zamanla küçük sorun işaretleri görünmeye başladı, kesintiler sıklaştı ve hızlı, akıcı deployment'lar acı verecek kadar yavaşladı.
Bu, Heroku'nun güçlü yanlarının kaybolmaya başladığı dönemin bir déjà vu'su gibi.
Ne kadar çok insan platforma gelirse performansın o kadar kötüleştiği, ne kadar popüler olursa o kadar az kararlı göründüğü yolda Fly.io'nun da ilerliyor olması üzücü.
Bu, umut vadeden bir platformun nasıl düşüşe geçebileceğini gösteren ibretlik bir hikâye gibi geliyor ve Fly.io'nun bu döngüden çıkıp Heroku'nun en dip dönemindeki kadar işe yaramaz hâle gelmeden önce kendine yer edinmesini umuyorum.
Sektörün vicdanını fazla abartmış olabilir miyiz diye düşündüm; Heroku kadar yaygın bilinir hâle gelirse para ödemek istemeyen insanların akın edeceği belliydi.
Bu kadar cömert ücretsiz kullanım sunmayı yeniden denemek istiyorsanız, ya güçlü ve pahalı bir kötüye kullanım önleme organizasyonunuz olmalı ya da başlangıçtaki yokluğu tolere edecek kadar donanıma para saçabilecek derin cepleriniz.
Fly bu iki tarafta da güçlü görünmüyor. Zaten biraz da bu yüzden seviyorum; bunlar büyük şirket tarzı saçmalıklar gibi duruyor ve Fly'da o koku daha az var.
Ama Fly mühendislerinin zamanlarının çoğunu uzun vadeli altyapı güvenilirliği ya da geliştirici deneyimi yerine, beleşçi kripto madencileri, dolandırıcıları ve kötüye kullanım yapanları ele almakla, kaynak tahsisini ve otomatik sınırlamayı optimize etmekle geçiriyor olmasına da şaşırmam.
Bunun ölçekle ilgili olup olmadığını merak ediyorum. Bir şirket, kârlılık ya da yatırım yapılabilirlik sağlayacak kadar ücretli müşteri kazandığında, acaba aynı anda yeterince problem de birikiyor ve ilk baştaki o taze, heyecan verici hissin yerini yavaş yavaş değiştirmeye çalıştığı eski rakibine benzeyen bir yapı mı alıyor?
Benim deneyimim de böyleydi. Şirket birkaç pizza ölçeğinden “mekânı tuttuk” seviyesine büyüyünce entropi sızmaya başlıyor ve Conway yasası ya da Brooks yasası gibi özdeyişler giderek daha görünür hâle geliyor.