Membangun budaya On-Call yang sehat

• Tips dari SoundCloud tentang "on-call", yaitu menetapkan engineer yang akan dipanggil (paging) dan menyelesaikan masalah saat terjadi insiden di luar jam kerja

1. Tugas on-call bersifat opsional (Optional, hanya bagi yang mendaftar)

2. Karena ini adalah kerja di luar jam kerja reguler, kompensasi dibayarkan per jam, dan ada tambahan bayaran per jam saat merespons paging

3. Engineer on-call terdiri dari beberapa rotasi

4. Setiap rotasi

→ terdiri dari kelompok engineer yang mewakili satu atau beberapa tim

→ selalu ada 1 engineer yang siaga untuk menangani dukungan tingkat pertama atas masalah dari semua tim dalam rotasi tersebut

→ engineer lainnya siaga untuk memberikan dukungan tingkat kedua yang menangani masalah layanan milik tim mereka sendiri

→ dukungan tingkat kedua berbasis upaya terbaik (best-efforts): mereka bisa menerima paging kapan saja dan akan berusaha semaksimal mungkin menanganinya jika memungkinkan, tetapi tidak wajib merespons saat memang tidak bisa

Mengapa tugas on-call baik bagi para engineer?

• Memasukkan beragam engineer ke tugas on-call, bukan hanya DevOps dan SRE(Site Reliability Engineers), baik untuk perusahaan maupun engineer itu sendiri

• Mengurangi beban engineer tim operasional yang selalu memiliki banyak kerja lembur

• Memotivasi engineer untuk membangun sistem yang stabil dan terdokumentasi dengan baik

→ melihat langsung saat masalah terjadi memberi wawasan tentang bagaimana memperbaiki dan membuat sistem lebih tangguh

• Mendukung sistem milik sendiri sekaligus sistem milik orang lain adalah kesempatan belajar yang bagus bagi engineer

Praktik terbaik prosedural: setiap organisasi berbeda, tetapi ini adalah proses terbaik yang ditemukan SoundCloud

• Setiap rotasi memiliki siklus pergantian yang berbeda, tetapi kebanyakan berganti setiap 1 hingga 2 hari

• Masuk on-call sekitar 3 hari per bulan adalah yang paling ideal. Lebih dari itu bisa menyebabkan burnout, dan lebih sedikit dari itu menjadi kurang efisien.

→ Artinya, jumlah ideal anggota dalam satu rotasi adalah 8~12 orang. Jika 10 orang, itu sempurna.

• Pilih manajer formal/informal di dalam rotasi untuk mengelola rotasi, seperti jadwal shift dan perubahan personel

→ Contoh) penyesuaian jadwal shift selama masa liburan

Tim rotasi dan organisasi

• Organisasi SoundCloud berkembang seiring waktu, dengan penggabungan/pemisahan/pembentukan tim baru/perpindahan tim antar divisi

• Namun tim rotasi on-call tidak berkembang secepat organisasi engineering

• Saat ini banyak rotasi yang bahkan tampak seperti kelompok acak dari tim-tim yang sama sekali tidak berhubungan

• Tetapi itu tidak menjadi masalah, dan upaya untuk mengubahnya dihentikan karena engineer mengajukan keberatan

Praktik terbaik kultural: demi keuntungan engineer on-call dan perusahaan secara keseluruhan, kembangkan norma dan sikap berikut

• Orang yang sedang on-call memang ingin berada di on-call. Engineer yang secara sukarela memikul tanggung jawab (dan menerima kompensasi) akan lebih termotivasi saat merespons insiden

• Masalah seperti siklus pergantian diputuskan melalui diskusi oleh engineer di masing-masing rotasi. Perusahaan tidak menyediakan prosedur standar untuk pola pergantian/waktu pergantian/serah terima shift antar individu

• Engineer on-call sering menghabiskan waktu di jam kerja reguler untuk menyelidiki agar masalah seperti ini tidak memburuk atau agar tidak perlu melakukan paging kepada orang lain di luar jam kerja

• Saat merespons insiden, engineer dapat memanggil engineer lain untuk meminta bantuan. Tidak ada yang suka menerima panggilan dukungan tingkat kedua di tengah malam, tetapi jika memungkinkan mereka tetap merespons dan membantu, sehingga nantinya bisa mengajari orang tersebut agar dapat menangani situasi serupa sendirian

• Setelah waktu yang wajar berlalu, pekerjaan bisa diserahkan dengan bebas kepada orang lain. Dalam kasus insiden besar atau berkepanjangan, jika engineer terlalu lelah sehingga tidak bisa bekerja secara efektif, sebaiknya serahkan ke orang lain dalam 4 jam atau bahkan lebih cepat

• Yang paling penting adalah, "mendorong budaya belajar, bukan budaya saling menyalahkan". Ini tidak bisa terlalu ditekankan

→ kesalahan adalah bagian yang tak terhindarkan dalam respons insiden, dan dengan belajar dari kesalahan, organisasi engineering dapat menjadi lebih kuat dan lebih cakap secara teknis

→ jika orang dihukum karena kesalahan, engineer akan takut bertindak saat menghadapi situasi baru, takut meminta bantuan, dan takut terhadap transparansi

→ pada akhirnya, dalam budaya saling menyalahkan, orang akan berhenti dari rotasi on-call atau meninggalkan perusahaan

Saat insiden besar terjadi

• Menangani gangguan seluruh situs atau insiden serius adalah hal yang membuat semua orang stres

• Ini juga merupakan stress test bagi budaya on-call perusahaan

• Yang paling penting adalah engineer bekerja bersama dan saling percaya

• Jika orang bisa mengakui apa yang tidak mereka ketahui, meminta bantuan kepada orang lain, berbicara jujur tentang kesalahan yang mereka buat, dan mengatakan bahwa mereka terlalu lelah untuk melanjutkan, masalah dapat diselesaikan lebih cepat

• Mendorong perilaku seperti ini harus dilakukan sebelum insiden besar terjadi. Engineer belajar dari pengalaman dengan merespons insiden kecil dan berkolaborasi dengan rekan kerja.

→ insiden kecil adalah latihan untuk insiden besar

[xguru]

• Budaya on-call yang dibangun GitHub https://id.news.hada.io/topic?id=3551

• GitLab On-Call Runbooks https://id.news.hada.io/topic?id=966

Karena startup kekurangan orang, rasanya memang harus selalu on-call..

Namun saat organisasi mulai sedikit membesar, hanya sebagian orang yang terus-terusan on-call, dan kita bisa melihat mereka burnout karena harus menyelesaikan masalah bahkan pada malam hari dan akhir pekan.

Pada dasarnya, sepertinya yang paling penting adalah membentuk budaya yang baik (saya sendiri juga merasa belum melakukannya dengan baik, jadi sedang banyak merenung..)