Bagaimana menerapkan prinsip empat mata untuk perbaikan darurat?

Pertimbangkan skenario ini (perbandingan apa pun dengan situasi dunia nyata adalah murni kebetulan):

3:07 pagi : panggilan dukungan masuk " Sesuatu dalam produksi turun, saya butuh bantuan Anda! ".
3:12 pagi : terhubung ke sistem (masuk diterima) ... dan tidak ada waktu untuk minum kopi.
3:15 pagi : beruntung Anda, segera Anda dapat menemukan masalah melalui beberapa pesan kesalahan di suatu tempat.
3:17 pagi : gunakan kotak alat SCM Anda untuk mengambil kode, perbaiki masalah, ujilah, bagus ... perbaikan saya berhasil!
3:20 pagi : berhubungan dengan tim Ops ~~Dev~~ untuk mengirimkan perbaikan dan agar produksi berjalan kembali.
03:21 : bendera merah ... " Untuk menghormati empat mata , kita perlu 2 mata lagi untuk mendapatkan persetujuan untuk perbaikan ini ".
3:22 pagi : ggggrrrreat, sekarang apa, siapa lagi yang bisa kita panggil (= bangun manajer)?

Jika Anda menerapkan beberapa prosedur persetujuan yang mirip dengan jawaban saya untuk " Apa implementasi yang mungkin (atau contoh) dari prinsip empat mata? ", Maka Anda kurang beruntung ... berikut adalah pilihan Anda:

Perbaikan Anda akan macet (baca: produksi akan turun) sampai 2 mata terlibat lagi.
Anda mencari cara untuk menyiasati mata yang hilang.

Jadi bagaimana menerapkan prinsip empat mata untuk perbaikan darurat? ... Agar produksi Anda berjalan dan berjalan cepat, yaitu sekitar 3:25 pagi ... Dan agar Anda juga dapat menutup panggilan (dan kembali ke tempat asal Anda)?

configuration four-eyes

— Pierre.Vriens
sumber

Anda memang menghubungi tim , yang berarti mereka seharusnya telah memberkati tambalan sehubungan dengan prinsip-prinsip persetujuan yang berlaku. Saya benar-benar mulai membenci pertanyaan retoris itu :( hanya pendapat saya, jangan repot-repot dengan itu

— Tensibai

@Tensibai bagaimana mungkin seseorang bisa "telah memberkati beberapa patch" (atau memperbaiki) dimuka, tidak tahu apa penyebab masalahnya ketika "Anda dihubungi"? Juga, dapatkah Anda lebih spesifik tentang retorika? Tidak cocok, ada yang lain?

— Pierre.Vriens

Maksud saya, Anda dapat menghubungi tim pada pukul 3:20, yang berarti bukan hanya Anda yang mendorong perbaikannya. Saya menggunakan retorika sebagai 'kasus hipotetis, berdasarkan pengalaman atau tidak, di mana Anda sudah tahu jawaban mana yang Anda tunggu'. Kurang lebih kekhawatiran saya pada meta saya merasa sendirian tidak tertarik dengan 'prinsip-prinsip umum' ini T / A jadi saya mungkin salah. Yang saya yakin adalah bahwa saya tidak akan mengunjungi Q / A dua kali tentang prinsip-prinsip generik jika saya adalah seorang beta outlander.

— Tensibai

Saya dapat mengatakan hal yang sama tentang pertanyaan Jenkins yang umum jika mereka datang sekarang

— Tensibai

Komitmen tidak akan dihitung sampai beta publik, untuk saat ini secara pribadi kami sedang membangun apa yang menurut kami 'dilakukan' oleh pengguna adalah pertanyaan yang patut dicontoh untuk situs ini, dan saya pikir kami memiliki banyak pekerjaan dalam 12 hari tersisa, atau saya mungkin hanya harus melalui 7 tahap kesedihan

— Tensibai

Jawaban:

Dalam dunia SCM di mana saya akrab dengan sebagian besar, skenario di atas biasanya ditangani oleh apa yang disebut " prosedur daftar disingkat- persetujuan.

Ini cetak biru:

Tentukan jam bisnis Anda, katakan mulai jam 8 pagi sampai 6 sore.
Tetapkan daftar persetujuan lengkap untuk (katakanlah) 3 tingkat persetujuan (untuk peran X, Y dan Z).
Tetapkan daftar persetujuan singkat (katakanlah) hanya 1 tingkat persetujuan (hanya untuk peran X).
Perubahan yang direncanakan selalu membutuhkan semua persetujuan dari daftar persetujuan yang lengkap.
Untuk perubahan yang tidak direncanakan , daftar persetujuan lengkap digunakan juga untuk mengumpulkan persetujuan yang diperlukan, asalkan persetujuan akan dikeluarkan selama jam kerja yang ditentukan.
Untuk setiap persetujuan atas perubahan yang tidak direncanakan yang akan dikeluarkan di luar jam kerja yang ditentukan:
- Hanya persetujuan dari daftar persetujuan singkat (seperti peran X di atas) yang diperlukan untuk mengesahkan perubahan. Dan setelah otorisasi oleh daftar persetujuan singkat diberikan, penyebaran perubahan (di lingkungan target) akan benar-benar dilakukan.
- Tetapi persetujuan pasca- tambahan akan dibutuhkan setelah itu (dalam jumlah jam / hari yang wajar), yaitu dari semua peran yang terkandung dalam daftar persetujuan lengkap (seperti peran Y dan Z di atas), yang tidak juga tercantum dalam daftar persetujuan singkat. (seperti peran X di atas). Dan jika dalam jumlah (di muka) yang disepakati jumlah jam / hari tidak semua pasca-persetujuan telah dikeluarkan (misalnya karena perbaikan bekerja pada waktu "ini", tetapi hanya seperti perbaikan sementara), maka perubahan tersebut mungkin akan mengalami kemunduran. . Meskipun ada setidaknya 1 persetujuan pasca beredar, perubahan ditandai sebagai "persetujuan pos menunggu".

Dengan solusi seperti itu di tempat, panggilan dapat ditutup sekitar 3:23 ... karena tidak akan ada lagi bendera merah pada 3:21 ... ggggrrreat, waktu untuk bir untuk merayakan perbaikan saya agar produksi berjalan lagi (bukan kopi) ... dan semoga persetujuan posting yang luar biasa akan segera hadir ...

— Pierre.Vriens
sumber

Dalam hal perbaikan darurat di luar jam kerja, lebih praktis untuk meminta lebih sedikit sign-off untuk perubahan daripada prosedur normal Anda. Secara umum, Anda dapat menggunakan perbaikan dan kemudian melakukan persetujuan pasca pada hari kerja berikutnya. Jika perbaikan tidak disetujui, perbaikan dapat dikembalikan dan diganti dengan solusi permanen.

Selama situasi pemadaman, prioritas nomor satu adalah mengembalikan layanan. Jika organisasi Anda tidak mengenali proses santai ini selama pemadaman, maka ya, satu-satunya pilihan Anda adalah mulai membangunkan lebih banyak orang untuk mendaftar.

— tayworm
sumber

Saya setuju dengan rekomendasi Anda, yang tampaknya mirip dengan rekomendasi saya sendiri (jawaban). Bisakah Anda memikirkan beberapa contoh di dunia SCM yang Anda kenal, dan BAGAIMANA Anda akan menerapkannya di sana? Jika demikian, dapatkah Anda mengembangkannya dalam jawaban Anda?

— Pierre.Vriens