Menetapkan batas tanggung jawab yang benar-benar diserahterimakan
Sebutkan proyek, kampanye, dan periode yang bersangkutan. Pergantian dapat mencakup pemantauan suatu batch, penerimaan hasilnya, atau penyiapan ekspor. Pergantian ini tidak secara otomatis mengalihkan keputusan bisnis, pembelian periode baru, atau hak untuk mengubah perangkat lunak. Tunjuk satu orang yang menerima pekerjaan, satu pengganti, dan penanggung jawab yang dihubungi untuk keputusan di luar cakupan.
Bedakan penyiapan akses dari serah terima tanggung jawab. Panduan khusus akses membahas identitas dan izin; di sini, pastikan penerima mengetahui cara menggunakan sarana yang disediakan dan menemukan informasi yang tepat. Jangan menyerahkan kata sandi di dalam lembar tersebut. Referensi akun pemesanan dan akses operasional menjalankan fungsi yang berbeda.
Merekam keadaan pekerjaan pada waktu yang tepat
Lembar serah terima harus menunjukkan tugas yang selesai, yang sedang berjalan, yang menunggu, dan selisih yang masih terbuka. Tambahkan waktu pencatatan ini, versi yang aktif, perubahan terakhir, dan operasi berikutnya. Kalimat seperti “semuanya normal” langsung kedaluwarsa begitu ada tugas yang gagal. Pengenal dan status bertanggal memungkinkan rekan mencocokkan lembar tersebut dengan apa yang benar-benar ia amati.
The Site Reliability Workbook menjelaskan pembacaan serah terima sebelumnya di awal pergantian dan penyiapan catatan serah terima untuk pergantian berikutnya. Untuk kampanye GPU Anda, sesuaikan prinsip ini menjadi beberapa fakta yang berguna: perkembangan yang diharapkan, pekerjaan yang terhambat, tindakan yang sudah dicoba, dan pihak yang telah diberi tahu. Lembar ini harus mengarahkan keputusan berikutnya, tanpa menjadi catatan lengkap setiap pesan.
Menulis prosedur yang membedakan mengamati, bertindak, dan berhenti
Prosedur operasional, atau runbook, menjelaskan suatu situasi dan tindakan yang diizinkan. Untuk setiap tindakan, sebutkan prasyaratnya, efek yang diharapkan, pemeriksaan setelah pelaksanaan, dan kondisi berhentinya. Ganti “jalankan ulang jika perlu” dengan aturan yang mengidentifikasi tugas terkait, memastikan tidak ada hasil yang sudah diterima, dan melarang peluncuran ulang secara bersamaan. Jika prosedur tidak mencakup kasus yang diamati, penerima tahu siapa yang harus dihubungi.
Tabel yang diusulkan mengatur keputusan tim Anda; tabel ini tidak membuat izin apa pun di Capordia. Ambang batas, orang, dan alat harus disesuaikan dengan proyek. Pisahkan juga kemungkinan teknis untuk menjalankan perintah dari izin untuk melakukannya: akses yang berfungsi tidak cukup untuk menyetujui penghapusan atau pengeluaran baru.
| Situasi | Tindakan yang direncanakan | Keputusan yang diperlukan |
|---|---|---|
| Tugas yang masih aktif | Amati status dan hasil terakhirnya | Sebelum interupsi apa pun |
| Kegagalan yang tercakup dalam prosedur | Jalankan ulang tugas yang teridentifikasi setelah memeriksa keluaran | Jika penyebabnya berbeda dari kasus yang didokumentasikan |
| Selisih hasil | Pisahkan keluaran dan beri tahu penanggung jawab | Sebelum publikasi atau penerimaan |
| Periode hampir berakhir | Siapkan ekspor dan laporkan kebutuhan yang tersisa | Sebelum pemesanan baru |
Minta penerima menjelaskan tindakan berikutnya
Selenggarakan sesi singkat berpasangan. Rekan yang mengambil alih membuka lembar tersebut, menemukan satu tugas, dan menjelaskan apa yang akan ia lakukan selanjutnya, serta apa yang tidak akan ia putuskan sendiri. Mintalah ia mengidentifikasi tujuan ekspor dan status kelanjutan yang dipilih. Demonstrasi yang sepenuhnya dipimpin oleh orang yang keluar dapat menyembunyikan informasi yang masih belum ada dalam dokumen.
Untuk orang yang baru di proyek ini, lengkapi serah terima ini dengan praktik terbatas. Bab Google SRE tentang pembelajaran membedakan dokumentasi yang perlu diketahui, kontak ahli, dan pertanyaan pemahaman. Pilih di sini satu operasi umum dalam lingkup uji coba; tidak perlu memicu insiden nyata atau menghentikan pemrosesan yang berguna untuk menilai pemahaman.
Contoh terselesaikan: meneruskan 128 tugas tanpa menjalankannya ulang dua kali
Dalam contoh fiktif ini, Camille menyerahkan tongkat estafet kepada Noor pada pukul 14.00 UTC. Kampanye ini mencakup 128 tugas: 96 diterima, 8 sedang berjalan, dan 24 menunggu. Jumlah 96 + 8 + 24 = 128 sesuai dengan inventaris. Namun, dua dari delapan tugas aktif baru saja gagal. Tanpa rekonsiliasi pada saat serah terima, Noor bisa saja memperlakukan gambaran yang sudah kedaluwarsa sebagai keadaan terkini.
Camille pun memperbarui catatan: 96 diterima, 6 sedang berjalan, 2 gagal, dan 24 menunggu. Kedua kegagalan termasuk kasus kelanjutan yang sudah diizinkan; Noor memverifikasi tidak adanya keluaran yang diterima dan proses yang masih aktif, lalu mengembalikannya ke status menunggu. Status menjadi 96 + 6 + 26 = 128. Enam tugas aktif terus berjalan. Noor mengonfirmasi pengambilalihan dan mencatat pemeriksaan berikutnya; Camille berhenti menjalankan tindakan pada cakupan ini.
| Waktu | Diterima | Sedang berjalan | Gagal | Menunggu |
|---|---|---|---|---|
| Sebelum rekonsiliasi | 96 | 8 | 0 | 24 |
| Setelah pembaruan | 96 | 6 | 2 | 24 |
| Setelah pengembalian ke status menunggu yang diizinkan | 96 | 6 | 0 | 26 |
Menangani ketidakhadiran, perubahan, dan akhir serah terima
Jika penerima tidak dapat mengonfirmasi serah terima, gunakan pengganti yang direncanakan dan perjelas siapa yang tetap bertanggung jawab sementara waktu. Hindari pesan yang dikirim ke beberapa orang tanpa penerimaan eksplisit. Ketika insiden sudah dibuka, sampaikan juga hipotesis yang telah dikesampingkan dan tindakan yang sedang berjalan; orang baru tidak boleh diam-diam mengulang intervensi yang sudah pernah dicoba.
Setiap kali referensi perangkat lunak berubah, perbarui prosedur dan tandai apa yang menjadi usang. Pada akhir kebutuhan, hubungkan ekspor yang diterima, tindakan tersisa, dan tenggat waktu ke register proyek. Periode 3, 7, atau 30 hari tidak diperpanjang hanya karena seorang kolega melanjutkan pekerjaan. Penyewaan berikutnya, jika diperlukan, tetap merupakan keputusan dan pesanan yang terpisah.
Pertanyaan untuk memutuskan
Apakah serah terima memerlukan dokumen panjang?
Tidak. Catatan singkat bisa cukup asalkan mencantumkan cakupan, status bertanggal, tindakan berikutnya, batas kewenangan, dan kontak yang berguna. Prosedur terperinci tetap ditautkan dari catatan ini. Uji terutama apakah penerima dapat menemukan dan menjelaskan langkah berikutnya.
Bisakah pekerjaan diserahkan hanya melalui pesan lisan?
Pertukaran lisan membantu memahami nuansa, tetapi tinggalkan jejak bertanggal tentang status dan kesepakatan kelanjutan. Jejak ini memungkinkan pemisahan antara apa yang sudah selesai dan apa yang masih harus dikerjakan, terutama jika orang ketiga ikut terlibat setelah serah terima.
Apa yang harus dilakukan ketika ada instruksi yang hilang dalam prosedur?
Penerima mencatat selisihnya dan meminta persetujuan penanggung jawab yang ditentukan sebelum tindakan yang dapat mengubah data atau menghentikan pekerjaan. Setelah itu, tambahkan keputusan tersebut ke prosedur beserta cakupannya. Improvisasi yang berhasil sekali tidak otomatis menjadi aturan umum.