Pelatihan Tertulis DevOps

Bagaimana Cara Mendorong Pembelajaran Berkelanjutan dalam DevOps?

Proyek perangkat lunak mengajarkan bahwa masalah tetap terjadi meski Anda memiliki daftar periksa, tinjauan sejawat, serta mekanisme pengendalian, audit, dan kepatuhan. Ini tidak terhindarkan. Sudah waktunya tim dan organisasi DevOps membangun budaya untuk menemukan masalah sendiri, belajar, dan memperbaiki diri. Budaya ini menerima bahwa masalah akan muncul dan menyiapkan tim untuk menghadapinya. Penyelesaian masalah seharusnya menjadi bagian pekerjaan sehari-hari dan mendukung pembelajaran serta perbaikan berkelanjutan. Perbesar dampak solusi dengan membuatnya transparan, tersedia, dan mudah diakses seluruh organisasi.

Netflix, salah satu organisasi DevOps terkemuka, membuat perangkat lunak internal bernama Chaos Monkey untuk menyimulasikan kegagalan besar di pusat data awan mereka. Chaos Monkey menghentikan server produksi secara acak agar tim lebih yakin bahwa operasinya tangguh dan stabil, serta mampu memberi layanan bermutu tanpa gangguan. Mereka belajar dari setiap kegagalan dan menggunakan pelajarannya untuk membuat sistem lebih stabil dan tangguh.

Memahami Pentingnya Budaya Belajar

Jika orang saling menyalahkan setelah insiden, timbul budaya takut di kalangan teknisi. Organisasi menjadi lambat, birokratis, dan penuh kepentingan politik. Alih-alih belajar dari kesalahan, makin tangguh, dan lebih cermat mencegah kesalahan, semua orang berusaha melindungi diri. Pekerjaan, masalah, bahkan solusi tidak pernah sepenuhnya terbuka.

Because problems are inevitable in complex systems, instead of finger-pointing, blaming and shaming the ones who cause problems, your organization should value actions to make problems visible in your daily work. It should encourage organizational learnings from errors and inefficiencies, so everyone in your DevOps organization can also learn and profit from these problems, solutions and knowledge.When engineers in your DevOps organization feel safe about giving details about mistakes, they voluntarily go extra mile and spend a lot of energy to make sure that a similar problem will not happen again in their own work center and in other work centers in your organizational value stream. If engineers are punished or even if they feel that they are punished when they do mistakes, then they will be afraid of making mistakes, so

1. Mereka mengerjakan lebih sedikit agar lebih jarang melakukan kesalahan.
2. Mereka tidak terbuka mengenai pekerjaan, masalah, dan solusi.
3. Mereka tidak terdorong mengubah solusi menjadi pembelajaran organisasi.
4. Masalah yang sama atau sangat mirip pasti terulang karena tidak ada yang meluangkan waktu dan tenaga untuk belajar, berbagi, mengajar, dan membuat masalah serta solusi terlihat.

Lakukan Tinjauan Pascainsiden Segera sebelum Penyebabnya Terlupakan

Tujuan tinjauan pascainsiden sederhana:

• Mengidentifikasi hal yang dilakukan dengan benar agar dapat dicoba kembali dalam situasi serupa.
• Mencatat hal yang seharusnya dilakukan secara berbeda agar teknik dapat disempurnakan di masa depan.
• Mencatat hal yang Anda lakukan secara keliru dan menyarankan pendekatan alternatif atau langkah pengamanan untuk menghadapi masalah serupa di masa depan.
• Mengetahui mengapa tindakan yang menyebabkan insiden itu masuk akal untuk dilakukan atau tidak dilakukan.

Membahas kesalahan sendiri menakutkan dan, di beberapa organisasi, berbahaya. Jika mengaku berbuat salah berarti membuka diri terhadap kritik atau tindakan disipliner, Anda mungkin memilih diam. Strategi ini merugikan karena kegagalan memahami kesalahan masa lalu biasanya membuatnya terulang. Organisasi yang serius memperbaiki diri memahami ini dan berupaya membangun proses dan budaya yang aman untuk membahas kesalahan.

Saat melakukan tinjauan pascainsiden, terima beberapa anggapan dasar:

• Semua orang berusaha sebaik mungkin sesuai pemahaman mereka.
• Kita mengambil keputusan di bawah tekanan dan dengan informasi yang tidak lengkap.
• Kita sering diminta menjalankan tugas yang belum pernah dilatihkan, dengan alat dan sumber daya yang kebetulan tersedia.
• Kesalahan tidak terhindarkan dalam keadaan seperti itu.
• Tujuan proses ini adalah meninjau apa yang terjadi dan mengambil pelajaran tanpa menyalahkan orang atau tindakannya.
• Hasil proses ini adalah penilaian atas proses kerja dan cara meningkatkannya, bukan penilaian atas individu atau kelompok.

Semua orang yang terlibat harus sepenuhnya menerima model “Tidak saling menyalahkan, kita di sini untuk belajar”. Banyak organisasi berupaya keras menciptakan lingkungan yang aman. FAA, misalnya, memiliki Aviation Safety Reporting System yang memungkinkan pilot yang melakukan “kesalahan” terhindar dari tindakan disipliner regulator jika mereka melaporkan insiden tersebut.

Tinjauan pascainsiden harus selalu menghasilkan langkah nyata untuk mencegah insiden terulang. Contohnya metrik telemetri baru, kasus uji otomatis baru, penentuan jenis perubahan yang memerlukan tinjauan kode tambahan, refaktorisasi kode, atau pengurangan ketergantungan antarbagian sistem yang sering menimbulkan masalah.

Bagikan catatan dan pelajaran dari tinjauan pascainsiden ke seluruh organisasi. Dengan begitu, temuan dari satu unit kerja menjadi pembelajaran bagi semua pihak. Ini juga menyampaikan pesan bahwa organisasi DevOps menghargai transparansi, keterbukaan, dan budaya belajar.

Selenggarakan Simulasi untuk Memperbaiki Sistem

Simulasi ini bukan acara tim membosankan yang dinikmati orang ekstrover sementara orang introver bermain ponsel agar waktu terasa cepat berlalu.

Dalam simulasi, kegagalan besar dibuat di sistem pengujian. Tim DevOps kemudian memperbaiki dan belajar dari kegagalan tersebut.

Contohnya, hentikan server penting untuk memeriksa apakah failover berfungsi tanpa mengganggu layanan. Tim kemudian menguji apakah dan bagaimana pemulihan dari cadangan atau infrastruktur sebagai kode (IaC) berjalan. Menemukan masalah melalui simulasi membantu tim membangun sistem yang tangguh dan toleran terhadap kegagalan serta mengambil pelajaran.

Saat mengatasi masalah, tim membangun hubungan dengan departemen lain sambil berlatih menghadapi kegagalan tanpa tekanan. Anda dapat menguji dan memperbaiki komunikasi serta proses pemecahan masalah di organisasi yang lebih luas.

Anda juga dapat mengamati sinyal lemah tentang potensi masalah lebih besar. Insiden berprioritas rendah yang sering muncul selama simulasi atau efek samping kecil yang hampir merusak komponen penting lain adalah sinyal yang perlu diperhatikan dan ditangani.

KESIMPULAN

Dorong tim mengambil risiko yang diperhitungkan. Organisasi DevOps berkinerja tinggi lebih sering melakukan kesalahan. Ini wajar dan diperlukan untuk belajar dan meningkatkan kinerja.

Organisasi berkinerja tinggi mengalami 80% lebih sedikit kegagalan kritis di produksi dibandingkan organisasi biasa. Artinya, jumlah insiden yang berdampak pada klien 5 kali lebih rendah. Karena itu, teknisi harus merasa bebas membuat kesalahan dan belajar darinya.