Gaya Kepemimpinan Werner Vogels: CTO Yang Membina AWS Dari Dalam Keluar

Fakta Utama: Werner Vogels (b. 1958) telah berkhidmat sebagai Ketua Pegawai Teknologi Amazon sejak 2005 (bersertai 2004 sebagai Pengarah Penyelidikan Sistem). Dia memegang PhD daripada Vrije Universiteit Amsterdam, di mana dia meneliti pengkomputeran perusahaan yang boleh diskalakan sebelum Amazon mengamnya. Dia adalah arkitek asas sistem teragih AWS dan teori utama sistem data yang konsisten pada akhirnya — idea yang diformalkan dalam kertas Dynamo yang dikarang bersama beliau (2007) yang mendasari DynamoDB. Prinsip "Semuanya gagal sepanjang masa" dan budaya DevOps "Anda membinanya, anda menjalankannya" beliau telah menjadi doktrin piawai industri. Dia telah menulis secara berterusan pada blog beliau All Things Distributed selama lebih 20 tahun, menjadikannya salah seorang daripada CTO yang paling lama menulis secara terbuka dalam teknologi.

Model Vogels Anda-Membinanya-Anda-Menjalankannya

Model Vogels Anda-Membinanya-Anda-Menjalankannya ialah kerangka kerja kepemimpinan kejuruteraan di mana pasukan yang merancang dan menghantar perkhidmatan perisian juga memiliki pengoperasian produksinya — memantau ia, bertindak balas kepada insiden, dan pembaikan kegagalan secara langsung. Dipasangkan dengan aksiom pendampingan "semuanya gagal sepanjak masa," model itu menganggap kegagalan sebagai keadaan pengoperasian yang dijangkakan dan bukannya pengecualian, memaksakan reka bentuk untuk pelenyapan yang anggun daripada baris pertama kod. Hasilnya ialah gelung maklum balas yang ketat antara keputusan reka bentuk dan akibat pengoperasian, yang Vogels berhujah adalah laluan paling cepat kepada keandalan perisian yang sebenar pada skala.

Werner Vogels adalah profesor sistem teragih di Vrije Universiteit Amsterdam apabila Amazon mengamnya pada 2004. Dia telah menulis tentang idea-idea ini secara berterusan pada blog All Things Distributed beliau sejak 2005. Dia bukanlah pengasas permulaan atau visioner produk. Dia adalah akademik yang telah menghabiskan tahun-tahun meneliti cara membina perisian yang boleh diandalkan yang tidak runtuh apabila komponen individu gagal.

Amazon memerlukan keahlian khusus itu kerana Amazon jatuh. Syarikat telah berkembang ke dalam kusut yang kompleks daripada kebergantungan — pasukan memanggil kod pasukan yang lain secara langsung, tiada had perkhidmatan yang jelas, penyebaran yang rosakan sistem yang tidak berkaitan. Vogels menyertai sebagai Pengarah Penyelidikan Sistem pada 2004 dan menjadi CTO pada 2005. Dia kemudian menghabiskan dua dekad berikutnya mekarang mandat kejuruteraan yang menjadi cetak biru untuk cara organisasi teknologi berskala besar menstruktur diri mereka.

"Anda membinanya, anda menjalankannya" adalah doktrin piawai di syarikat-syarikat dia tidak pernah bekerja untuk. Mandat API, seni bina microservices, dan idea bahawa pasukan pembangunan harus memiliki sistem mereka dalam pengeluaran — ini adalah idea-idea berkaitan-Vogels malah apabila namanya tidak dilampirkan.

Apa yang membuat dia berguna untuk dikaji bukan hanya hasil teknikal. Ia adalah cara minda akademik yang digunakan pada masalah pengamal menghasilkan prinsip yang terskalakan kepada perniagaan $100 bilion.

Pecahan Gaya Kepemimpinan

Pembahagian 60/40 menjelaskan mengapa Vogels dikaji baik sebagai arkitek teknikal dan sebagai pembina budaya. Seni bina pertama API adalah sumbangan struktur. Sikap kerendahan pengamal adalah apa yang memungkinkan ribuan jurutera untuk melaksanakan seni bina itu dengan jujur, termasuk dalam tempat di mana ia sukar dan perlahan.

Ciri-Ciri Kepemimpinan Utama

Keputusan 3 Yang Menentukan Werner Vogels

1. Mandat API

Mandat API Bezos — terikat secara langsung kepada pertumbuhan Amazon Web Services — sering digambarkan sebagai idea Jeff Bezos. Itu sebahagiannya tepat. Bezos menulis mandat. Tetapi Vogels menjalankannya, menggunakannya, dan membina prinsip arkitektur di sekelilingnya.

Mandat, kira-kira: setiap pasukan mesti mendedahkan data dan fungsi melalui antara muka perkhidmatan. Tiada integrasi pintu belakang, tiada pembacaan pangkalan data langsung daripada sistem pasukan yang lain, tiada kod dalaman bersama. Semua komunikasi berlaku melalui antara muka. Dan antara muka mesti dirancang supaya mereka boleh didedahkan kepada pembangun luaran — bukan kerana Amazon merancang untuk mendedahkan mereka, tetapi kerana kekangan itu memaksa anda merancang antara muka yang sebenarnya bersih dan bukannya jalan pintas yang mudah.

Akibat perniagaan daripada mandat itu ialah AWS. Amazon terpaksa membina infrastruktur perkhidmatan dalaman yang boleh diandalkan cukup dan bersih cukup untuk berkhidmat kepada pelanggan luaran. Perkhidmatan yang mereka jalankan secara dalaman — pengiraan, storan, pangkalan data, pemesejan — ternyata adalah perkhidmatan syarikat lain memerlukan juga. AWS bukanlah dirancang sebagai produk daripada permulaan. Ia berkembang daripada disiplin seni bina dalaman yang Vogels membela dan menguatkan.

Untuk pengamal hari ini, prinsip mandat API diterjemahkan kepada: apa dalam organisasi anda diintegrasikan melalui hubungan tidak formal, akses data langsung, atau kebergantungan yang tidak didokumentasikan dan bukannya melalui antara muka yang jelas dan dimiliki? Integrasi tidak formal itu adalah hutang operasi anda. Apabila mana-mana satu komponen berubah, semua yang bergantung kepadanya dalam cara yang tidak didokumentasikan rosak dalam cara yang tidak dijangka. Mandat API tidak memerlukan membina API REST untuk komunikasi pasukan dalaman — ia memerlukan bertanya siapa memiliki setiap sistem, apakah kontrak antara sistem, dan apa yang berlaku apabila komponen gagal atau berubah.

2. "Anda Membinanya, Anda Menjalankannya"

Vogels mengartikulasi prinsip ini dalam temu bual 2006, tetapi dia telah melaksanakannya di Amazon selama dua tahun sebelum itu. Konsep mendahului pergerakan DevOps dengan beberapa tahun dan mengantisipasi kebanyakan apa DevOps akhirnya dikodimasikan.

Hujah itu mudah: jurutera perisian membuat keputusan reka bentuk yang berbeza apabila mereka tahu mereka akan dihalaman pada 2am jika sistem gagal. Empati pengoperasian — pemahaman cara kod anda berkelakuan dalam pengeluaran — dibina melalui memiliki akibat keputusan anda. Apabila dev dan ops adalah pasukan berasingan, kecerunan insentif adalah salah selaras: dev mahukan untuk menghantar ciri, ops mahukan kestabilan, dan serah di antara mereka menjadi rundingan dan bukannya tanggungjawab bersama.

"Anda membinanya, anda menjalankannya" menghapuskan serah itu. Pasukan yang menghantar ciri juga memantau ia, bertindak balas kepada insiden, dan membetulkan masalah yang muncul dalam pengeluaran. Itu mencipta gelung maklum balas langsung antara keputusan reka bentuk dan akibat pengoperasian — cara paling cepat untuk meningkatkan keandalan perisian.

Model ini memerlukan pelaburan. Anda perlu membina pemantauan, memberi amaran, dan alat on-call yang membuat pemilikan pengeluaran boleh diuruskan untuk jurutera pembangunan. Anda perlu mencipta budaya di mana insiden pengeluaran diperlakukan sebagai peluang pembelajaran dan bukannya insiden prestasi — sebaliknya akauntabiliti on-call mencipta jenis ketakutan yang mengurangkan gelung maklum balas. Dan anda perlu merekrut jurutera yang bersedia mengambil akauntabiliti itu, yang bukan semua jurutera adalah.

Amazon melakukan pelaburan itu, dan rekod keandalan AWS mencerminkan ia. Andy Jassy, yang membina dan memimpin AWS sebelum menjadi Ketua Pegawai Eksekutif Amazon, menskalakan budaya pemilikan ini merentasi ribuan jurutera — menunjukkan model berfungsi pada saiz jauh di luar apa kebanyakan pemerhati fikir mungkin apabila Vogels pertama kali mengartikulasi ia. Syarikat-syarikat yang mengambil "anda membinanya, anda menjalankannya" selepas melihat kejayaan AWS sering mengambil ungkapan tanpa pelaburan infrastruktur asas, yang adalah mengapa beberapa pelaksanaan model membakar pasukan kejuruteraan.

3. Surat CTO Tahunan

Setiap tahun di AWS re:Invent, Vogels menerbitkan surat terbuka yang semakan komitmen Amazon daripada tahun sebelumnya, mengakui tempat Amazon jatuh pendek, dan menetapkan keutamaan untuk tahun mendatang. Dia telah melakukan ini sejak tahun-tahun awal AWS.

Format itu — komitmen awam tahunan dengan semakan akauntabiliti yang eksplisit — adalah luar biasa untuk CTO korporat. Kebanyakan surat tahunan adalah berorientasi hadapan: di sini adalah rancangan menggembirakan kami untuk tahun seterusnya. Surat-surat Vogels adalah berorientasi ke belakang pertama: di sini adalah apa yang kami berkata kami akan lakukan, di sini adalah apa yang kami lakukan, di sini adalah apa yang kami tidak lakukan dan mengapa.

Kesannya adalah dua kali ganda. Secara luaran, ia mencipta kepercayaan dengan pembangun dan komuniti pelanggan perusahaan bahawa komitmen AWS dibuat dengan niat baik, kerana ada rekod terbuka sama ada komitmen sebelumnya dihormati. Secara dalaman, ia mencipta standar akauntabiliti yang mengalir melalui organisasi: jika CTO secara terbuka bertanggungjawab untuk apa yang AWS akan sampaikan, setiap pasukan yang menyumbang kepada komitmen itu memahami bahawa kegagalan untuk menyampaikan mempunyai akibat sebenar.

Model itu boleh dipindah. Kebanyakan organisasi membuat komitmen dalam kitaran perancangan suku tahunan dan mengevaluasi mereka dalam retrospektif yang tidak pernah terbentuk secara terbuka. Sumbangannya ialah akauntabiliti terbuka, dinyatakan secara spesifik cukup untuk boleh dibuktikan salah, mengubah cara serius komitmen itu diambil.

Apa Yang Werner Vogels Akan Lakukan dalam Peranan Anda

Jika anda seorang CEO, prinsip mandat API terpakai kepada antara muka organisasi anda, bukan hanya perisian anda. Setiap kali satu pasukan mendapat maklumat daripada yang lain melalui hubungan tidak formal dan bukannya proses yang didokumentasikan, anda telah mencipta kebergantungan yang tidak didokumentasikan. Ia berfungsi baik sehingga orang di tengah hubungan itu meninggalkan, jatuh sakit, atau menukar peranan. Tanya COO anda untuk memetakan aliran maklumat kritis dalam organisasi anda dan mengenal pasti yang ada hanya kerana individu khusus mengekalkan mereka. Itu adalah titik kegagalan tunggal operasi anda. Vogels akan membuat antara muka itu jelas dan dimiliki dan bukannya tidak formal dan bergantung pada orang.

Jika anda seorang COO, "anda membinanya, anda menjalankannya" mempunyai setara pengurusan operasi: orang yang merancang proses harus mengalami akibat cara ia berfungsi. Jika pasukan operasi anda merancang aliran kerja pada kapal (onboarding) yang wakil kejayaan pelanggan benci, dan pasukan operasi tidak pernah bercakap dengan pelanggan atau wakil secara langsung, gelung maklum balas adalah rosak. Membina setara pemilikan pengeluaran ke dalam reka bentuk proses anda: siapa sahaja yang menentukan proses harus menghabiskan masa dalam sistem yang mereka tentukan, secara tetap cukup untuk merasakan geseran yang mereka telah cipta.

Jika anda seorang pemimpin produk, prinsip "semuanya gagal sepanjak masa" Vogels adalah bernilai menggunakan kepada keperluan produk anda. Kebanyakan keperluan produk adalah spesifikasi laluan bahagia: apa yang berlaku apabila semua berfungsi. Keperluan yang menarik — yang menentukan keandalan produk anda — adalah mod kegagalan: apa yang berlaku apabila panggilan API gagal, apabila pengguna kehilangan sambungan pertengahan-aliran, apabila integrasi pihak ketiga mengembalikan data yang tidak dijangka. Tanya pasukan anda berapa peratusan dokumen keperluan anda meliputi laluan kegagalan. Jika ia di bawah 20%, anda merancang produk yang akan berkelakuan tidak dijangka dalam pengeluaran dalam cara anda tidak mengantisipasi.

Jika anda berada dalam jualan atau pemasaran, model komunikasi terbuka jangka panjang Vogels mempunyai aplikasi langsung dalam pengurusan akaun dan kejayaan pelanggan. Kebanyakan komunikasi vendor adalah berorientasi hadapan: di sini adalah apa yang kami membina, di sini adalah jalan raya kami, di sini adalah apa yang datang. Pendekatan Vogels adalah berorientasi ke belakang pertama: di sini adalah apa yang kami berkomitmen kepada, di sini adalah apa yang kami sampaikan, di sini adalah tempat kami jatuh pendek dan mengapa. Pelanggan perusahaan paling penting anda akan bertindak balas lebih baik kepada format itu daripada kepada dek jalan raya suku tahunan yang lain. Mereka tahu produk anda mempunyai jurang. Soalan yang mereka sebenarnya bertanya ialah sama ada anda jujur tentang mereka.

Bagaimanakah Rework Menterjemahkan Doktrin Kejuruteraan Vogels kepada Pemilikan Pasukan Kecil

Vogels membina model beliau atas anggapan bahawa anda mempunyai bilangan kepala untuk meletakkan setiap perkhidmatan di sebalik pasukan yang memilikinya dalam pengeluaran. Kebanyakan syarikat yang menjalankan pada Rework tidak. Apa Rework lakukan ialah meruntuhkan jurang antara "siapa yang merancang aliran kerja" dan "siapa yang menjalankan ia setiap hari" di dalam permukaan operasi tunggal — orang yang menetapkan saluran CRM, peraturan automasi, dan logik pengurangan ialah orang yang sama yang mendapat halaman apabila perjanjian terhenti atau SLA rosak. Itu adalah versi pasukan kecil "anda membinanya, anda menjalankannya," dan ia berfungsi kerana isyarat kegagalan dan pembaikan hidup dalam alat yang sama. Rework juga mengenkod sikap "semuanya gagal sepanjat masa" ke dalam lalainya: setiap automasi mempunyai keadaan kegagalan yang kelihatan, setiap medan pemilik diperlukan, dan setiap serah adalah acara yang dicatat dan bukannya DM Slack. Untuk pasukan operasi 10-orang, itulah laluan realistik kepada standar keandalan Vogels — anda tidak boleh merekrut pasukan platform, tetapi anda boleh membuat pemilikan dan kegagalan kelihatan oleh pembinaan.

Petikan Terkenal & Pelajaran Seterusnya di Sebalik Lembaga Pengarah

Daripada blog All Things Distributed beliau: "Semuanya gagal sepanjat masa." Pernyataan itu, yang dia telah kembali kepada dalam berbagai bentuk merentasi lebih 20 tahun penulisan, menangkap prinsip sistem teragih teras: keandalan bukan tentang mencegah kegagalan. Ia adalah tentang merancang sistem yang terus berfungsi apabila komponen gagal. Dalam perisian, itu bermakna pelenyapan anggun, pemutus litar, dan logik percubaan semula. Dalam organisasi, itu bermakna merancang proses yang terus berfungsi apabila orang kunci tidak tersedia, vendor tidak menyampaikan, atau sistem turun.

Di re:Invent 2022, Vogels menggambarkan janji awan dengan cara ini: "Keupayaan untuk bereksperimen pada kos yang rendah adalah salah satu hadiah kuasa paling teknologi memberikan kami." Itu bukan pernyataan pemasaran — itu adalah satu arkitektur. Apabila anda boleh memutar infrastruktur dalam minit dan membayar hanya untuk apa yang anda gunakan, kos percubaan yang gagal jatuh kepada hampir sifar. Itu mengubah apa yang bernilai mencuba. Kebanyakan organisasi dengan infrastruktur warisan membuat keputusan pertaruhan-suku-tahunan tentang infrastruktur kerana kos salah adalah tinggi. Hujah Vogels ialah tindak balas yang betul kepada ketidakpastian adalah membuat kos percubaan rendah, bukan meningkatkan unjuran anda.

Dia juga berbicara jarang tentang kegagalan beliau sendiri, yang menjadikan contoh apabila dia melakukan terkenal. Dalam temu bual 2022, dia mengakui bahawa pilihan pangkalan data awal Amazon mencipta hutang migrasi yang ketara yang mengambil tahun untuk menyelesaikan. Jeff Dean di Google menghadapi detik arkitektur yang serupa — jenis yang berlaku apabila sistem dibina untuk satu skala berhenti bekerja di yang seterusnya — dan kesediaan untuk menamakan itu secara terbuka ialah apa yang memisahkan jurutera yang menjadi pengetahuan institusi daripada jurutera yang menjadi mitologi institusi. Kesediaan untuk menamakan keputusan teknikal khusus yang ternyata salah — bukan vaguely mengakui bahawa kesilapan dibuat — ialah standar intelektual dia menetapkan secara terbuka dan nampaknya memegang secara dalaman.

Tempat Gaya Ini Pecah

"Anda membinanya, anda menjalankannya" memerlukan jurutera senior yang bersedia memiliki pengeluaran. Ia berfungsi buruk dalam permulaan terkekang kos dengan pasukan junior, kerana beban on-call pada pasukan kecil dengan pengalaman terhad boleh menjadi tidak boleh terus cepat. Amazon boleh melabur dalam pemantauan, alatan, dan infrastruktur tindak balas insiden yang membuat pemilikan pengeluaran boleh diuruskan. Permulaan 15-orang tidak boleh.

Mandat pertama-API juga memperlahankan syarikat peringkat awal yang perlu bergerak cepat. Menguatkan had perkhidmatan bersih sebelum anda tahu apa produk anda mencipta overhed yang tidak perlu. Prinsip Vogels dioptimalkan untuk organisasi yang sudah mempunyai kesesuaian pasaran produk dan menskalakan kerumitan. Mereka adalah alatan yang salah untuk menemui kesesuaian pasaran produk pada tempat pertama.

Dan kunci dalam platform ialah kritik yang sah daripada pendekatan seni bina AWS. Apabila anda membina sangat dalam primitif AWS — DynamoDB, SQS, Lambda — pindahan ke awan yang berbeza atau on-premise menjadi mahal. Hujah tolak Vogels ialah kecekapan pengoperasian sekarang ialah portabiliti yang bernilai kos kemudian. Pertukaran itu adalah nyata, dan ia adalah keputusan setiap pemimpin kejuruteraan harus membuat secara eksplisit dan bukannya terlepas ke dalamnya.

---

Untuk bacaan berkaitan tentang seni bina kejuruteraan dan penskalaan, lihat Gaya Kepemimpinan Linus Torvalds, Gaya Kepemimpinan Andy Grove, dan Gaya Kepemimpinan Martin Fowler.