Pernahkah Anda mengatakan bahwa Anda mengatakan sesuatu yang sangat normal bagi Anda, tetapi semua orang sangat terkejut? Ini terjadi pada saya secara konstan ketika saya menggambarkan apa yang dianggap normal di perusahaan tempat saya bekerja. Untuk beberapa alasan, wajah lawan bicaranya berangsur-angsur berubah dari senyum yang menyenangkan menjadi seringai keheranan yang luar biasa. Berikut ini beberapa contoh tipikal.

Ada satu perusahaan yang sangat bagus, salah satu tempat paling menyenangkan yang pernah saya kerjakan, kombinasi dari semua barang-barang Valve dan Netflix. Orang-orang di sini luar biasa, dan mereka memberi Anda kebebasan hampir sepenuhnya untuk melakukan apa pun yang Anda inginkan. Tetapi sebagai efek samping dari budaya semacam itu, sekitar 50% karyawan baru meninggalkan mereka di tahun pertama, sebagian secara sukarela dan sebagian tidak. Sangat normal, ya?

Ada perusahaan yang sangat tertutup tentang infrastrukturnya. Misalnya, takut melaporkan bug ke pemasok peralatan, karena kesalahan akan diperbaiki dan pesaing akan dapat menggunakan koreksi. Ini tidak diizinkan. Solusi: minta firmware dan perbaiki bug sendiri! Baiklah

Baru-baru ini, saya bertemu dengan spesialis yang mencoba mereproduksi algoritma yang dipublikasikan dalam artikel perusahaan itu. Mereka tidak dapat mereproduksi hasilnya. Selain itu, algoritma dari artikel tersebut menyebabkan tingkat ketidakstabilan yang sangat tinggi. Ketika salah satu penulis ditanya tentang ini, dia menjawab: "Ya, ada beberapa trik yang tidak muncul dalam artikel," dan menolak untuk membagikan trik ini. Artinya, perusahaan sengaja menerbitkan hasil yang tidak produktif agar tidak memberikan rincian, seperti yang biasanya dilakukan dengan bug.

Perusahaan mengancam akan memecat karyawan yang membocorkan informasi secara instan. Ini diceritakan kepada setiap pendatang baru dengan contoh-contoh orang yang dipecat karena kebocoran (misalnya, satu orang membocorkan informasi bahwa konser akan berlangsung di kantor tertentu). Setiap pemecatan seperti itu dilaporkan dengan keras dan dikomunikasikan kepada semua karyawan. Sebagai akibat dari kebijakan ini, banyak yang takut untuk meneruskan email bahkan dengan informasi yang tidak bersalah seperti memperbarui data asuransi. Sebagai gantinya, mereka mencetak surat dari komputer lain - dan mengirimkannya dalam bentuk kertas. Atau ambil gambar di telepon. Baiklah

Di satu kantor, saya pernah bertanya mengapa dua karyawan tertentu tampaknya saling menghindari. Saya diberi tahu bahwa permusuhan mereka telah berlangsung selama sepuluh tahun. Bahkan, situasinya telah membaik belakangan ini. Selama bertahun-tahun, mereka benar-benar tidak bisa berada di ruangan yang sama, jika tidak salah satu dari mereka akan menjadi terlalu marah dan melakukan sesuatu yang tidak menguntungkan. Tetapi sekarang orang-orang telah tenang, sehingga mereka kadang-kadang dapat ditemukan di sayap kantor yang sama atau bahkan di ruangan yang sama. Dan ini bukan hanya orang acak. Ini adalah manajer dari dua tim saja di perusahaan ini. Oke!

Ada perusahaan dengan budaya aneh sehingga Anda bisa menulis buku kecil tentangnya. Bahkan, saya baru-baru ini mulai menulis posting tentang perusahaan ini, dan sudah menulis lebih dari 100 ribu kata - lebih dari semua posting di blog saya digabungkan.

Perusahaan ini menjelaskan kepada saya bahwa jauh lebih baik untuk membuat keputusan bukan berdasarkan data, tetapi berdasarkan hubungan politik, dan bahwa ide membuat keputusan berdasarkan data adalah mitos - tidak ada yang melakukannya.

Di perusahaan ini saya diberi empat alasan untuk bekerja bersama mereka. Keempatnya ternyata bohong. Akibatnya, tanggung jawab pekerjaan saya mengarah pada kenyataan bahwa ketika saya mempekerjakan, saya setuju untuk tidak melakukan apa pun.

Ketika saya bergabung dengan perusahaan ini, tim saya tidak menyentuh sistem kontrol versi selama beberapa bulan. Saya harus berjuang untuk membuat semua orang menggunakannya. Saya memenangkan pertempuran ini. Tapi dia tidak bisa meyakinkan karyawan untuk melakukan tes terlebih dahulu. Karena itu, majelis istirahat beberapa kali sehari.

Dalam percakapan dengan manajemen, saya mengisyaratkan bahwa saya menganggap ini masalah produktivitas departemen kami. Saya diberitahu bahwa ini normal. Ini adalah situasi untuk semua karyawan, sehingga setiap orang memiliki kedudukan yang sama. Tugas saya adalah memberi peringkat pada mereka, jadi jika masalahnya mempengaruhi semua orang secara setara, maka tidak ada alasan untuk khawatir.

Perusahaan lain meluncurkan banyak inisiatif berskala besar untuk menarik pengembang wanita, tetapi wanita masih disaring untuk wawancara dengan pertanyaan seperti "Apakah Anda memiliki pengalaman dengan algoritma atau hanya coding?" Saya pikir kandidat saya dengan rekomendasi yang sangat baik akan melewati penghalang ini tetapi lupa betapa normal perusahaan itu.

Di perusahaan lain, saya bekerja dalam tim beranggotakan empat orang dengan proyek dengan anggaran beberapa ratus juta dolar dan efek tahunan satu miliar dolar. Pada saat yang sama, permintaan barang senilai ratusan dolar dipertimbangkan selama berbulan-bulan atau ditolak.

Tampaknya bagi Anda bahwa saya hanya bekerja di perusahaan yang luar biasa buruk. Tetapi tidak, mereka memiliki reputasi yang baik, dan dua di antaranya dianggap sebagai salah satu perusahaan terbaik untuk pekerjaan. Dan saya mendengar cerita serupa dari karyawan perusahaan lain, bahkan dengan reputasi teknik yang sangat baik. Satu-satunya perbedaan adalah sekarang saya kaget, dan teman bicara saya percaya bahwa semuanya baik-baik saja.

Banyak perusahaan menggunakan pustaka Flaky , yang menambahkan anotasi python ke pengujian tidak andal yang lulus atau gagal. Saya bertanya kepada karyawan dari tiga perusahaan berbeda apa yang Flaky lakukan. Mereka semua menyarankan agar dia berulang kali menjalankan tes dan melaporkan jika terjadi kegagalan. Tutup, tetapi tidak cukup. Secara teknis, itu bisa digunakan, tetapi dalam praktiknya berulang kali me-restart tes dan melaporkan penyelesaian yang sukses. Flaky dikembangkan oleh perusahaan yang berurusan dengan infrastruktur penyimpanan data, sementara perpustakaan aktif menggunakan pesaing terbesarnya. Menandai sebagai tes yang lulus dengan potensi bug sepenuhnya normal .

Ada perusahaan yang dikenal karena praktik rekayasa yang baik. Ketika saya terakhir memeriksa, dia memiliki uptime 99,99%, yang sepenuhnya dijelaskan oleh praktik rekayasa yang diterapkan di sana. Jika startup terlihat seperti Twitter atau Reddit, maka hanya satu sembilan yang cukup, tetapi kita berbicara tentang platform infrastruktur yang benar-benar membutuhkan dua. Banyak perusahaan yang membangun infrastruktur untuk dua sembilan menganggap praktik mereka yang menyebabkan keandalan seperti itu benar-benar normal.

Sejauh yang saya tahu, banyak dari perusahaan-perusahaan ini telah berjalan jauh. Pada awalnya, mereka hanya fokus pada pertumbuhan produk. Ini sangat masuk akal, karena pada awalnya nilai perusahaan kira-kira nol. Dia tidak menerapkan administrasi sistem yang kompeten atau keamanan nyata, karena dia tidak akan rugi. Nah, dengan pengecualian data pengguna, ketika mereka diretas, dan jika Anda berbicara dengan petugas keamanan di perusahaan swasta besar (mereka disebut "unicorn," unicorn), maka ini selalu terjadi.

Hasilnya adalah budaya yang terlalu fokus pada pertumbuhan tanpa risiko. Budaya ini sering dilestarikan bahkan ketika perusahaan telah tumbuh hingga satu miliar dolar dan sudah ada sesuatu yang hilang. Jika seseorang pernah bekerja untuk Google, Amazon atau perusahaan lain dengan prosedur yang solid, maka situasinya akan mengejutkannya. Seringkali ia mencoba memperbaiki sesuatu, tetapi tidak dapat melakukan apa pun dan mengundurkan diri.

Mungkin, Google saat ini memiliki praktik operasional dan metode keamanan terbaik di antara semua perusahaan IT di dunia. Mudah untuk mengatakan bahwa kita harus mengambil contoh darinya. Tapi itu instruktif untuk melihat bagaimana mereka mencapai ini. Dan apa yang terjadi sebelumnya. Jika Anda melihat basis kode, Anda akan melihat banyak layanan yang namanya berakhir dengan z, serta sejumlah besar variabel yang mengejutkan. Salah satu karyawan lama mengatakan bahwa suatu ketika seseorang ingin menambahkan pemantauan. Tidak terlalu aman untuk mengatur google.com/somename untuk dipantau, jadi mereka menambahkan z, yaitu google.com/somenamez , untuk keamanan. Ini ada di perusahaan, yang sekarang dianggap sebagai yang terbaik di dunia dalam keamanan.

Sekarang dia telah bergerak sejauh ini dengan aman sehingga karyawan baru dengan keras menyangkal praktik semacam itu di masa lalu. Pada saat yang sama, alasan disebut yang tidak terlalu masuk akal (misalnya, untuk menghindari tabrakan nama).

Kemajuan keamanan Google yang luar biasa - dari menambahkan huruf z ke praktik IB terbaik di dunia - tidak terjadi karena seseorang membuat pidato berapi-api atau menulis esai yang menarik. Itu dimulai setelah beberapa "fakap". Baru pada saat itulah penjaga keamanan diberi wewenang untuk menyelesaikan masalah mendasar. Untuk perusahaan yang baik dan benar, reformasi hampir selalu dimulai dengan cara ini. Microsoft ditertawakan selama bertahun-tahun, tetapi kemudian beberapa eksploitasi bencana memaksa mereka untuk mengubah sikap mereka terhadap keamanan. Itu terdengar sederhana. Tetapi saksi mata mengatakan perubahan itu kejam. Meskipun ditunjukkan dari atas, kelembaman tetap sangat kuat. Mengapa mengubah apa yang berhasil? Oleh karena itu, ada tekanan yang sangat kuat dari orang-orang yang terbiasa melakukan semuanya dengan cara lama.

Hal-hal seperti itu dapat dilihat dalam industri apa pun. Contoh klasik yang sering dikutip oleh teknisi adalah cuci tangan oleh dokter dan perawat. Telah diketahui bahwa mikroba ada, dan mencuci tangan dengan sabun sangat mengurangi kemungkinan penularan mikroba dan dengan demikian secara signifikan mengurangi tingkat kematian di rumah sakit. Meskipun demikian, dokter dan perawat berpengalaman sekalipun masih sering tidak. Diperlukan intervensi. Tanda-tanda yang mengingatkan pada mencuci tangan menyelamatkan nyawa. Dan yang lebih baik lagi, orang yang hidup itu berdiri dan menuntut untuk mencuci tangan: dengan cara ini semakin banyak nyawa yang diselamatkan. Orang-orang dapat mengabaikan tanda-tanda, tetapi mereka tidak dapat melewati orang yang bertanggung jawab.

Sesuatu seperti ini, perusahaan IT sedang mencoba menerapkan praktik terbaik. Jika Anda memberi tahu karyawan apa yang harus dilakukan, itu sedikit membantu. Jika Anda menerapkan verifikasi kode, efeknya langsung terlihat.

Statistik jelas menunjukkan bahwa orang benar-benar kurang menguasai kebiasaan rutin yang tidak memberikan efek yang terlihat, tetapi secara permanen mengurangi risiko peristiwa langka tapi bencana. Tampaknya bagi seseorang bahwa memotong jalan adalah rute yang benar dan masuk akal. Ada istilah khusus untuk ini: "normalisasi penyimpangan." Ini telah dipelajari dengan baik dalam sejumlah konteks lain, termasuk perawatan kesehatan, penerbangan, teknik, teknik aerospace, dan teknik sipil, tetapi belum dibahas dalam konteks perangkat lunak.

Apakah mungkin untuk belajar dari kesalahan orang lain, dan bukan dari kesalahan Anda sendiri? Keadaan industri tidak memberikan alasan untuk mengandalkan ini, tapi mari kita coba. John Banya menulis laporan singkat tentang normalisasi penyimpangan layanan kesehatan , yang temuannya dapat diterapkan untuk pengembangan perangkat lunak. Dapat dicatat bahwa perawatan pasien dapat dibandingkan dengan tindakan devops. Namun, normalisasi penyimpangan juga terjadi dalam konteks budaya di mana analoginya tidak begitu jelas.

Bagian pertama artikel ini menjelaskan secara rinci sejumlah situasi bencana, baik dalam perawatan kesehatan maupun di bidang lain. Berikut adalah satu contoh khas:

Kasus kelalaian bencana, yang penulis amati sebagai saksi ahli, dihubungkan dengan ahli anestesi mematikan alat ventilasi paru buatan atas permintaan seorang ahli bedah yang ingin mengambil rontgen rongga perut pasien (Banya, 2005, hal. 87-101). Ventilator seharusnya mati hanya beberapa detik, tetapi ahli anestesi lupa untuk menyalakannya kembali atau mengira itu menyala, tetapi tidak menyalakannya. Pasien bebas oksigen cukup lama untuk memulai anoksia lengkap, yang menjerumuskannya ke kondisi vegetatif. Dia tidak pernah pulih. Setelah 9 hari, ia terputus dari ventilasi mekanis, dan setelah 2 hari ia meninggal. Kemudian ditemukan bahwa alarm anestesi dan peralatan pemantauan di ruang operasi sengaja diprogram untuk "menangguhkan tanpa batas waktu" sedemikian rupa sehingga ahli anestesi tidak menerima peringatan tentang masalah dengan ventilator. Alarm itu sendiri ada di tempatnya, tetapi dimatikan, mungkin karena staf operasi menemukan perangkat menjerit menjengkelkan.

Matikan atau abaikan notifikasi karena terlalu banyak dan terlalu mengganggu? Bertindak secara manual dengan risiko melakukan kesalahan? Ya, saya dapat menyebutkan beberapa perusahaan sekaligus, di mana pembekalan setelah bencana dimulai justru dari titik-titik ini, kecuali pada akhirnya tidak ada yang meninggal, dan hanya beberapa juta dolar yang hilang. Jika Anda membaca banyak analisis tentang insiden seperti itu di TI , maka setiap contoh dalam artikel Bunny akan terasa familier bagi Anda, walaupun detailnya berbeda.

Bagian ini diakhiri dengan kesimpulan ini :

Sebagai aturan, bencana ini dijelaskan oleh “pelanggaran panjang terhadap aturan, peristiwa kontradiktif yang terakumulasi tanpa terdeteksi, dan gagasan budaya yang salah tentang bahayanya. Bersama-sama, faktor-faktor ini mencegah intervensi yang bisa mencegah efek berbahaya. " Sangat mengejutkan bagaimana banyak pelanggaran aturan dan kesalahan digabungkan bersama untuk menciptakan peluang bencana.

Sekali lagi, teks tersebut tampaknya berasal dari artikel tentang kegagalan teknis. Oleh karena itu, bagian selanjutnya tentang penyebab kegagalan ini patut mendapat perhatian. Dan alasannya adalah sebagai berikut.

Aturan konyol dan tidak efektif

Artikel tersebut memberikan contoh pemberian obat kepada bayi baru lahir. Untuk mencegah "kebocoran obat," perawat harus memasukkan kata sandi di komputer. Dia mendapat akses ke kotak obat dan mengambil jumlah obat yang tepat. Untuk memastikan bahwa perawat pertama tidak mencuri apa pun, perawat kedua harus memantau prosesnya. Kemudian dia harus memasukkan kata sandi ke dalam komputer sebagai konfirmasi bahwa dia telah mengamati prosedur yang benar untuk menangani obat.

Kedengarannya familiar. Banyak laporan kejadian dimulai dengan fakta bahwa "seseorang melompati beberapa langkah karena mereka tidak efektif." Misalnya, "seorang programmer meluncurkan konfigurasi yang buruk atau kode yang buruk karena ia yakin akan hal itu dan tidak ingin menghabiskan waktu untuk mementaskan atau menguji." Pematian Azure yang terkenal buruk pada November 2014 terjadi karena alasan ini.

Pada waktu yang hampir bersamaan, salah satu pesaing Azure, pengembang membatalkan aturan yang melarang mendorong konfigurasi yang gagal tes ke cabang Canary. Pengembang yakin bahwa konfigurasi sudah beres. Ketika Canary mulai gagal, mereka membatalkan aturan yang melarang penyebaran dari Canary ke Staging dengan kesalahan. Mereka yakin bahwa konfigurasi sudah beres, dan bahwa kegagalan itu disebabkan oleh sesuatu yang lain. Analisis selanjutnya menunjukkan bahwa konfigurasi secara teknis benar, tetapi dengan itu bug memanifestasikan dirinya dalam perangkat lunak utama. Sangat beruntung bahwa bug tersembunyi yang diungkapkan oleh konfigurasi tidak seserius bug Azure.

Orang-orang memiliki pemahaman yang buruk tentang bagaimana kesalahan tumpang tindih. Karena itu, kami menerima aturan untuk penerapan yang aman. Tetapi untuk alasan yang sama bahwa orang memiliki pemahaman yang buruk tentang bagaimana kesalahan tumpang tindih, aturan-aturan ini tampak konyol dan tidak efektif!

Pengetahuan tidak sempurna dan tidak merata

Konsep norma bukanlah bawaan. Ketika orang baru datang ke perusahaan, mereka dengan mudah menyerap proses menyimpang yang telah menjadi norma.

Julia Evans menjelaskan kepada saya bagaimana ini terjadi:

pendatang baru datang
Pemula : WTF WTF WTF WTF WTF
Veteran : Ya, kami tahu, kami melakukan ini.
pemula : WTF WTF wTF wtf wtf ...
pemula terbiasa
pemula kedua datang
rookie No. 2 : WTF WTF WTF WTF
pemula : ya, kami tahu, kami melakukan ini.

Hal yang paling berbahaya adalah orang-orang benar-benar menerima gagasan WTF, dan kemudian mereka dapat menyebarkannya sendiri di tempat lain sepanjang karier mereka. Suatu ketika saya bekerja dengan satu proyek open source yang sering macet. Saya diberitahu bahwa ini normal, dan produk mereka lebih baik daripada rata-rata. Saya memeriksa dan menemukan bahwa dia adalah yang terburuk di kelasnya dalam hampir semua hal. Dan dia membuat sketsa ide tentang bagaimana melepaskan build dengan usaha yang relatif sedikit, yang hampir selalu lulus tes. Jawaban yang paling umum adalah: “Wow, orang ini pasti bekerja dengan programmer superstar. Tapi kami akan realistis. Semua orang istirahat setidaknya beberapa kali seminggu. " Seolah menjalankan tes (atau, dalam hal ini, bahkan mencoba mengkompilasi) sebelum memeriksa kode memerlukan upaya manusia super. Tetapi begitu orang percaya bahwa beberapa jenis penyimpangan adalah normal, mereka sering benar-benar menyerap ide itu.

Saya melanggar aturan demi kebaikan pasien

Artikel itu memberikan contoh seorang dokter yang melanggar aturan bahwa sarung tangan harus dipakai saat mencari vena. Dia percaya bahwa mengenakan sarung tangan membuat sulit untuk menemukan pembuluh darah, jadi dia harus menusuk anak dengan jarum beberapa kali. Sulit untuk berdebat dengan itu. Tidak ada yang mau melukai anak!

Kegagalan terbesar kedua dari semua yang saya lihat dalam hidup saya terjadi karena alasan ini. Seseorang memperhatikan perlambatan basis data. Mereka dengan cepat menulis tambalan, dan agar degradasi tidak menyebar lebih jauh, mereka mengabaikan aturan penyebaran yang lambat dan bertahap. Sebaliknya, mereka menggulung tambalan ke semua mesin. Sulit untuk berdebat dengan itu. Tidak ada yang ingin pelanggan mengalami penurunan layanan! Sayangnya, tambalan mendeteksi kesalahan yang menyebabkan shutdown layanan global.

Aturan tidak berlaku untuk saya / Anda bisa mempercayai saya

, . , , , .

, . , : « ? , X, Y Z?»

, Facebook . Facebook. , - , . , , . «» «», .

, , . . , - , . , .

, . , , , . , : . , , - . , . .

, . — , .

, . , - . , , . . , , .

, : , . , . ?

— , . , . , : , .

, , . , - , , . — . , «» , .

. , : (IC) -> (TL) -> (CEO). . , - , . , , , . - , . , , . , . .

. , . , , , , . , . .

, , . , . , . . , . . , .

Agak lucu bahwa pada akhirnya semuanya bermuara pada masalah insentif. Kami di industri berpikir banyak tentang bagaimana mendorong konsumen untuk melakukan apa yang kami inginkan. Namun di dalam perusahaan, kami menciptakan sistem insentif yang mendorong kami untuk melakukan hal-hal yang salah. Semacam campuran telepon rusak dan kultus kargo. Di masa lalu, Microsoft adalah panutan - kami menyalin metode mereka dan meminta teka-teki wawancara. Sekarang Google telah menjadi model - dan kami mengajukan pertanyaan tentang algoritma . , Google, Google, . , Google , . , Google . , -. , Google .

. Stripe Mongo , Mongo ¹ . - ² .

, .

• .
  
• .
  
• .
  
• , .
  
• , .

, , “WTF WTF WTF”.

-, . . , - , . , , . , . , , , .

« » , ? , . . ? ? , .

, . . , , . , . , . , , . , , . .

, , , — . , , , . — .

, , . . , , , , . , . , , TDD Agile, , — .

---

1. , , . mongodb message queue . « MongoDB ». , , , . . , . . , . , , Mongo, , , , . []

, . « 30 », « 10 , , » « , , », « , ». , , , , . . , , . , , .

2. , , . , , . , , , , , . . , - , , , , . , . . , . , - — . : - , . , . , , - , . []