Sekitar setahun yang lalu, tugas yang agak serius telah ditetapkan di depan saya: untuk memberi kuliah 2 jam bagi para manajer tentang kisah Agile dan DevOps.
Maka dimulailah saya kembali dari bidang softskill pelatihan Agile ke IT. Dan menurut panitia, lebih dari 1000 manajer produk melewati kuliah ini, di mana sekitar 48/50 orang mendengar kata "Load Balancer" untuk pertama kalinya di kelas saya.
Saya bahkan mendapat dewa komik "penyeimbang yang hebat, ahli pembaruan tanpa downtime, murah untuk menerapkan tes A / B tanpa pemrograman, dan umumnya tidur nyenyak seorang manajer."
Tentu saja, kolega-kolega dari IT mungkin menertawakan penyederhanaan ini, dan bahkan menjadi marah karena dunia tidak menyetujui kata "penyeimbang" dan seberapa banyak perhatian dapat diberikan padanya.
Tetapi ketika di gym saya 48 orang dari 50 tidak mendengar tentang fenomena load balancing, itu sedikit sedih. Ya, dan para pengembang menjadi backend dari beberapa aplikasi mobile, bahkan bank-bank besar dapat berbuat dosa dengan tidak adanya skema tersebut.
Bank kuning favorit saya, misalnya, memperbarui server backend aplikasi seluler pada pukul 5 pagi waktu Moskow sekitar 2 kali seminggu. Kenapa saya tahu itu? Karena di Novosibirsk, tempat saya kembali untuk tinggal selama satu tahun pada tahun 2016, saat itu sudah jam 9 pagi, dan kesalahan 000 muncul. Sungguh mengerikan membayangkan bahwa ini sudah makan siang untuk Timur Jauh.
Mungkin kita memiliki kesempatan untuk membuat dunia ini sedikit lebih baik jika manajer akan berpikir tentang toleransi kesalahan pada saat penganggaran kapasitas server, dan tidak akan ada 1 server untuk semuanya, tetapi tingkat risiko dan konfigurasi beban sistem yang benar-benar sepadan.
Mengapa
Pertanyaan pertama yang muncul ketika mengatur tugas apa pun, tentu saja: mengapa?
Ada kerangka kerja seperti itu:Mengapa kita membutuhkannya? | Mengapa mereka membutuhkannya?
Mengapa kita membutuhkannya?
Jika kita membayangkan bahwa "kita" adalah banyak orang dari TI, tidak hanya pengembang dan spesialis terkait, tetapi juga konsultan teknologi, pelatih SDM dan Agile, yang setiap hari berhubungan dengan manajer yang tidak memiliki latar belakang TI.
Bagi saya sendiri, saya menjawab pertanyaan pertama dengan cukup sederhana: meningkatkan literasi teknis para manajer sangat mengurangi kemungkinan tugas yang tidak memadai dan meningkatkan kebahagiaan pengembang.
Mengapa mereka membutuhkannya?
Mengapa manajer yang benar-benar jauh dari TI tahu tentang ini?Kita semua orang, dan kita semua ingin tidur nyenyak. Manajer sering mengambil tanggung jawab untuk sesuatu yang mereka tidak dapat benar-benar pengaruhi. Tingkat stres dalam hal ini sebanding dengan penumpang pesawat yang memiliki aerophobia.
Dan ini mungkin satu-satunya argumen yang tidak akan seperti keangkuhan "yah, bagaimana Anda tidak bisa mengetahui hal-hal yang jelas" atau "siapa pun yang pada malam hari harus ditutup matanya menyederhanakan integral yang tidak terbatas". Dalam pengalaman saya, jika seseorang "ke siku di konsol", maka bahkan secara tidak sadar, tetapi dia sering dapat beroperasi dengan perangko seperti itu.
Bagaimana saya bisa menjelaskan gambar-gambar sederhana yang kompleks
Ilustrasi di bawah ini tidak mengklaim kebenaran absolut dan tidak memiliki nilai independen, terutama karena penyederhanaan ini tidak boleh digunakan sebagai panduan untuk bertindak ketika membangun arsitektur toleran-kesalahan, karena saya tidak bermaksud untuk menggambar berbagai titik halus di sana, seperti caching. Ini hanya model yang disederhanakan.
Dalam pembelajaran orang dewasa, dan asimilasi informasi baru adalah bagian dari pembelajaran, penting untuk memahami bahwa informasi apa pun harus diulang setidaknya tiga kali untuk meningkatkan kemungkinan bahwa itu sebenarnya diperoleh.
Sebagai contoh, skema semacam itu kemungkinan besar akan dikaitkan dengan meme "jangan coba-coba meninggalkan Omsk" dan hanya mengkonfirmasi orang tersebut dalam pemikiran bahwa "semuanya rumit, tetapi mereka juga menginginkan banyak server".
Namun skema ini, yang ditunjukkan pada awalnya, dapat membuat asosiasi seseorang dari kata "penyeimbang" dengan fenomena menyeimbangkan beban di server. Tanpa jaminan pemahaman yang benar tentang proses ini, tetapi dengan keyakinan bahwa proses itu ada dan mengapa diperlukan.
Mari kita merusak beberapa poin dari
manifest Agile di tempat ini dan mengatakan "yaitu, tanpa mengurangi nilai apa yang ada di kanan, kita lebih menghargai apa yang ada di sebelah kiri."
Misalnya, karena skema ini memungkinkan Anda untuk memahami cara mengkonfigurasi sistem pengujian A / B tanpa menulis banyak kode sumber, dan cara memperbarui server tanpa meminum keberanian (kepada manajer, bukan ke admin) sebelum itu.
Apa selanjutnya
Dan pemahaman ini sangat membuka jalan bagi manajer ke dunia CI / CD yang indah, karena jika kita sudah tahu tenaga kerja minimum yang diperlukan untuk membuat infrastruktur sebagian toleran terhadap kesalahan, kita kurang takut akan seringnya rilis. Dan ini secara fundamental mengubah pendekatan untuk memperbarui kebijakan secara umum.
Yah, bukan bagi saya untuk memberi tahu Anda bahwa pengeditan yang lebih kecil diletakkan pada 1/10 dari kapasitas (bahkan jika itu adalah 1 server dari 3, tetapi hanya 10% dari lalu lintas diberikan untuk itu), ini adalah penurunan kuat dalam gairah selama peningkatan. Bahkan jika server benar-benar berhenti memproses setiap permintaan ke-10.
Kami pernah mengalami penurunan 20% di RPS 600, dan dengan cepat dihilangkan, tampaknya bahkan tanpa partisipasi orang. Saat itulah saya, sebagai PM teknis, yang bertanggung jawab atas semua backend dari arah, praktis mulai dengan aspirasi mengulangi kata "penyeimbang" kepada manajer lain.
Seperti yang ditunjukkan oleh pengalaman saya, pengetahuan ini sangat berguna secara tepat sehingga manajer dapat memahami bagaimana meminimalkan risiko dari rilis dan menjadi tertarik pada CI / CD dan berbagai eksperimen teknologi.
Sekitar 4 tahun yang lalu, kira-kira kisah yang sama dalam praktik saya memberi tahu pengembang tentang sistem "brunching" seperti GitFlow untuk menstabilkan rilis dan moratorium komitmen di cabang rilis, didukung pada level hook, tetapi belakangan ini menjadi semakin berkurang. dan kurang dibutuhkan.
Menurut pendapat saya, sekarang sangat penting untuk meningkatkan literasi teknis para manajer non-teknis. Tentu saja tidak dengan cara seperti ini.