Tugas adalah komponen penting dari sebagian besar organisasi modern. Bagaimanapun, sering terjadi bahwa masalahnya tiba pada pukul 3 pagi. Tapi siapa yang harus bertugas? Dan bagaimana mengatur proses ini sehingga masuk akal?
Lihat di bawah kucing, di sana Baruch Sadogursky (
@jbaruch ) dan Leonid Igolnik (
@ligolnik ) menceritakan kisah horor tentang seorang petugas yang tidak berhasil. Ingat Vasya, yang selalu harus
memperbaiki bug pada jam tiga pagi? Ini baru permulaan.
Materi disiapkan berdasarkan pidato Baruch dan Leonid pada konferensi musim gugur 2017.
Begitu bertugas. Sebagai contoh, ambil hipotesis Vasya, yang telah bekerja di perusahaan tertentu belum lama ini, sekitar setahun. Hari ini adalah hari Jumat dan kebetulan Vasya sedang bertugas. Semuanya berjalan baik: Vasya sedang tidur, dan mimpinya indah.
Meskipun ia tidak mencurigai apa pun, kolega dukungan teknisnya menerima telepon dari klien. Dia mengatakan bahwa pada hari Senin dia harus menunjukkan kepada CEO demo yang sangat penting, tetapi sesuatu tidak berhasil. Kebutuhan mendesak untuk memperbaiki masalah. Dukungan melakukan apa saja yang bisa dilakukan (disarankan mematikan dan menghidupkannya) dan meningkatkan masalah ini kepada petugas.
Vasya bertugas sendirian untuk seluruh proyek, dia harus melakukan ini. Seorang insinyur dukungan teknis membangunkannya dan mencoba menjelaskan masalahnya dengan kata-kata yang sangat sederhana: "Ada yang tidak berfungsi di sana, ada yang salah."
Vasya mendengarkan rekannya, merenungkan apa yang telah terjadi dan membuat satu-satunya keputusan yang tepat ...
Insinyur pendukung tersinggung, tetapi masih meminta klien untuk menunggu hingga Senin. Klien tidak setuju dengan keadaan ini dan meneruskan masalahnya ke manajer pendukung. Sekarang dia menelepon Vasya dan mengatakan bahwa ini tidak serius: "Tetap saja, masalahnya penting, klien khawatir, itu perlu." Vasya adalah orang yang bertanggung jawab. Itu harus diperlukan: kopi dan menari (mencari sesuatu di log).
Dalam log, semuanya ternyata jauh dari sederhana. Pertama, Vasya mencari seseorang dengan akses ke log yang benar selama 15 menit. Dia menemukannya dan mengambil log. Tapi bagaimana caranya? Untuk mengirim dalam format .doc, tentu saja. Vasya bertanggung jawab, muda dan membaca log di Word: tidak ada yang dipahami sama sekali. Tetapi ada kata kunci yang dapat Anda cari di Pangkalan Pengetahuan. Vasya bergantung pada hal-hal menarik selama sekitar 20 menit, belajar banyak hal menarik, tetapi tidak ada yang dibutuhkan saat ini.
Apa yang dilakukan Vasya selanjutnya? Anda perlu mencari seseorang, tetapi Vasya adalah seorang insinyur muda dan menakutkan untuk membangunkan Senior. Karena itu, ia memutuskan bahwa Anda perlu menelepon seorang kolega, junior yang sama.
Seorang kolega adalah teman yang baik, dengan setengah kesedihan mereka mengerti apa masalahnya dan mulai menyelesaikannya. Setelah dua hingga tiga jam kerja, mereka menemukan perbaikan terbaru. Itu harus segera diberikan kepada produksi. Tapi bagaimana caranya? Ada papan kontrol perubahan, yang bertemu setiap hari Senin setiap dua minggu. Tetapi opsi ini tidak cocok, Anda sangat membutuhkannya.
Secara alami, Anda tidak dapat menggunakan untuk produksi, tidak ada root. Jadi satu-satunya pilihan adalah mengirim file jar dengan dua kelas dan satu paragraf penjelasan melalui email. Orang-orang itu akan masuk ke produksi melalui ssh dan di sana mereka akan menempatkan file jar ini di WebSphere ke direktori yang benar. Dan sekarang, pukul 6-7 pagi, Anda akhirnya bisa pergi tidur dengan perasaan puas.
Pada hari Senin, Vasya datang ke kantor dan melihat gambar yang tidak biasa. CEO meneriaki VP of Engineering karena klien meneriaki CEO karena CEO-nya meneriaki dia. Ternyata itu tidak mungkin untuk menyelesaikan masalah.
Pihak berwenang memiliki empat pertanyaan: "Apa yang terjadi pada hari Jumat?"; "Mengapa saya mendengar tentang hal ini dari bos pada hari Senin?"; "Mengapa perbaikannya memakan waktu enam jam?" dan "Siapa yang harus disalahkan?" Ops dipanggil ke dalam ruangan, yang mengatakan bahwa ini bukan masalah mereka. Vasya dan pelayan lainnya dipanggil ke ruangan, yang juga mengatakan, "Tidak ada yang berhasil." Seluruh permainan kentang ini berlanjut hingga makan siang.
Karena sudah waktunya untuk makan malam, keputusan "OK, itu rusak dengan sendirinya, tidak ada yang bisa disalahkan." Akhir dari cerita.
Mari kita mengatur pembekalan kecil: mari kita pergi melalui mimpi buruk ini dan mencoba memberikan jawaban untuk semua pertanyaan.
Siapa yang harus bertugas
Sysadmins (atau kata yang lebih modis - SRE) dapat bertugas. Mereka sudah melakukan ini selama beberapa tahun, semuanya sudah beres. DBA bisa bertugas, mereka yang terlibat dalam olahpesan dapat. Jika Anda beruntung, NOC (pusat operasi jaringan) sedang bertugas - ini adalah saat semua orang ini ditempatkan di ruangan yang sama. Mereka memiliki buku pedoman yang mengatakan apa yang harus dilakukan dalam situasi yang sulit.
Semuanya jelas dengan orang-orang ini, mereka pro bertugas. Tapi, sayangnya, DevOps memiliki bagian kedua dari persamaan, yang tidak benar-benar ingin bertugas. Bagaimana cara membuat bagian kedua? Ya, dan apakah perlu untuk memaksa, karena pro harus menyadari pentingnya tugas.
Ada dua alasan mengapa orang tidak mau bertugas. Salah satunya adalah ketika demikian:
Tidak ada yang mau bertugas ketika semuanya buruk. Solusi untuk masalah ini cukup sederhana:
Anda perlu menulis kode yang baik, semuanya sederhana. Tetapi ini juga perlu dipelajari. Muncul pertanyaan baru: "Bagaimana caranya belajar?". Anda harus meletakkan jari Anda di soket - #painisinstructional. Nyeri membantu.
Tugas dengan sendirinya meningkatkan kualitas kode. Vasya yang sama pada hari Senin, kemungkinan besar, akan memperbaiki kesalahannya agar tidak duduk satu malam lagi untuk mencari kesalahan.
Hambatan bertugas
Saat bertugas, ada beberapa hambatan yang seharusnya tidak ada. Mari kita pergi melalui kegagalan Jumat Vasya. Ingat bagaimana dia membaca log dalam dokumen kata?
Kita semua menyukai produk Microsoft, tetapi Anda tidak dapat melakukannya di dunia modern. Ada hal-hal yang jelas tentang log yang harus dipahami semua orang.
Poin utama adalah sejumlah alat yang memecahkan masalah ini: Logstash, Loggly, Sumo logic, Kibana. Mereka perlu digunakan.
Kembali ke pertanyaan tentang akses: mengapa tidak memberikan akses ke log? Jawabannya adalah data sensitif. Klien dijanjikan untuk melindungi data dari kebocoran. Ini berarti bahwa log tidak dapat ditampilkan kepada siapa pun atau Anda perlu menggunakan sistem dengan fungsi masking data. Dia sendiri menyembunyikan data pribadi dan tidak menunjukkannya kepada seseorang tanpa tingkat akses yang diperlukan. Semua alat parsing log hari ini memiliki fungsi ini.
Keuntungan lain dari alat-alat ini adalah “pemantauan untuk orang miskin” dapat dibangun di atasnya. Misalnya, dalam log, setelah melihat sejumlah kesalahan (antrian penuh, dll.), Anda dapat memicu alergi.
Siapa yang menentukan pentingnya masalah
Bagaimana cara memahami, pergi bertugas atau menjalankan tugas yang mendesak untuk memperbaiki masalah? Siapa yang menunjuk keparahan? Siapa yang memutuskan seberapa kritis masalah itu? Memecahkan dukungan. Mengapa Karena dukungan memiliki visi tentang masalah. Dia tahu betapa buruk semuanya.
Terlebih lagi, saat ini hampir semua perusahaan bekerja dengan prinsip "Pengiriman Berkelanjutan", sehingga semua pelanggan menerima semua fitur pada saat yang sama (dan pada saat yang sama bug). Misalkan ada bug yang bagi klien terlihat seperti "Sesuatu tidak berfungsi di sana, tidak apa-apa." Pada saat yang sama, dukungan melihat ratusan peringatan tentang masalah ini, dan ini jelas serius.
Klien juga terlibat dalam menentukan pentingnya masalah. Tetapi ada masalah - klien tidak selalu percaya bahwa masalah kecilnya akan diperbaiki dan menempatkan kepentingan tertinggi. Keparahan mulai digunakan sebagai alat manipulasi. Tetapi jika keparahan definisi dibangun dengan benar dan klien memahami apa itu SLA, ini biasanya tidak terjadi. Ini adalah proses pembelajaran bersama ketika pelanggan mulai memahami apa yang sebenarnya sangat penting dan apa yang sebenarnya penting.
Klien perlu diberi kesempatan untuk menunjukkan kepentingannya karena produsen produk tidak selalu memahami konteks masalah.
SLA - jaminan respons dan solusi dalam sehari, tetapi bisa lebih cepat. Ini, sekali lagi, tergantung pada konteksnya.
Tantangan Organisasi
Vasya tidak mengerti masalah sampai akhir. Tentu saja, dia baru saja bangun, dan seorang rekan dukungan teknis juga menjelaskan dengan buruk. Ini diperlakukan hanya dengan satu cara: tiket. Tiket adalah nomor referensi yang menceritakan semua tentang tiket itu. Ini diperlukan untuk Vasya, karena alih-alih telepon, dukungan dapat memberi tahu Vasya “Buka sistem manajemen tiket kami dan lihat nomor tiket 42”. Ini perlu karena beberapa alasan. Pertama, Vasya, alih-alih mendengarkan seorang rekan dalam keadaan mengantuk, akan bangun, membaca tiket dan memahami betapa pentingnya hal ini. Kedua, mungkin ada lebih dari satu masalah.
Ada kesulitan lain yang memengaruhi gambaran keseluruhan: Vasya perlu ditemukan. Bagaimana dukungan tahu bahwa Vasya bertugas hari ini? Bagaimana jika dia juga tidak mengenal Vasya. Penting bagi Anda untuk menemukan orang yang tepat. Solusinya adalah Virtual Extension dengan berbagai awalan untuk insinyur, produksi, dll. Nah, atau sistem lain yang lebih canggih. Dengan solusi ini, Anda tidak perlu menebak ke mana harus menelepon di tengah malam; semuanya beralih secara otomatis.
Yang lebih nyaman adalah Obrolan Eskalasi di Slack, Telegram, Skype, di mana saja. Judul obrolan adalah nomor tiket yang sama. Semua komunikasi pada tiket ini antara orang yang tepat masuk ke ruang obrolan ini. Salah satu fitur yang paling berguna dari obrolan semacam itu adalah bahwa Anda tidak perlu memberi tahu apa pun kepada mereka yang bergabung dengan pekerjaan setelah beberapa saat. Anda cukup membaca tentang keputusan apa yang sudah dibuat.
Ya, jembatan telepon virtual, yang dapat dibandingkan dengan tempat berkumpul jika terjadi kebakaran: semua orang tahu ke mana harus pergi jika ada masalah. Omong-omong, dalam sistem modern seperti Zoom atau Bluejeans, semua fungsi yang diperlukan sudah ada di dalamnya.
Jalur eskalasi
Vasya takut memanggil tuan, karena mereka mengerikan. Apa hubungannya dengan itu? Mari kita bicara tentang jalur eskalasi. Anda harus selalu tahu siapa dan kapan harus bangun atau berangkat kerja. Ini harus sangat jelas bagi semua orang: kepada orang yang bangun, dan kepada orang yang bangun. Anda juga perlu tahu harus menelepon ke mana jika jalur pertama tidak berhasil. Jalur eskalasi yang baik berlaku sampai ke CEO perusahaan.
Ada komunikasi yang harus datang dari CEO. Dia harus sadar akan masalah kritis.
Manajer tugas
Posisi menarik berikutnya adalah manajer yang siap dipanggil. Dia tidak harus menjadi seorang teknisi dan mengambil bagian dalam memecahkan masalah. Pertama, Vasya di tengah malam tidak bisa memberi tahu klien apa pun yang bermanfaat. Manajer tugas dapat membantu dalam situasi ini. Selain itu, ia dapat terlibat dalam koordinasi, manajemen proyek dalam situasi yang sulit, manajemen sumber daya. Bagaimanapun, pekerjaan harus berjalan dengan lancar.
Akses ke Produksi
Haruskah saya memberi Vasya akses ke produksi? Lagi pula, tidak semua adalah insinyur yang brilian, dan ada hal-hal tertentu yang saya tidak ingin pelajari, pelanggan akan tersinggung. Ini diselesaikan dengan menggunakan proses penyebaran. Jika prosesnya dikonfigurasi dengan benar, maka Vasya dapat mengklik tombol, yang sebagai hasilnya, kode produksinya akan dinonaktifkan. Jika Anda memiliki pipa pengiriman kontinu normal, kemungkinan besar ini dapat dilakukan secara otomatis (semua tes akan berlalu). Jika tidak, di banyak perusahaan keputusan dibuat oleh insinyur atau manajer senior. Dia meninjau, mengevaluasi risiko kode, dan membuat keputusan.
Dan bahkan sebelum perbaikan terbaru muncul, alat yang terdokumentasi untuk pemecahan masalah harus dilibatkan. Salah satu masalah paling umum yang bertugas: ia mulai berpikir bagaimana menyalakan debug atau mengubah tingkat log. Pada saat yang sama, tidak ada masalah dengan yang lainnya. Dianjurkan untuk memiliki solusi terdokumentasi untuk masalah.
Pergantian tugas
Sekarang mari kita bicara tentang proses tugas, yang biasanya memakan waktu seminggu. Pada titik tertentu perlu diubah. Untuk berubah secara efisien, ini harus dilakukan pada waktu tertentu. Hal ini diperlukan untuk merencanakan segala sesuatu dengan jelas dan diinginkan untuk dapat secara efektif mentransfer masalah kepada orang berikutnya yang bertugas. Di banyak perusahaan ini dilakukan sebagai reli standar, atau halaman dibuat di mana petugas membuat majalah kecil.
Masalah lainnya
Ada berbagai masalah lain yang perlu diatasi. Salah satunya adalah sertifikasi akses ke produksi. Dianjurkan untuk melakukan sertifikasi dasar sehingga seseorang menunjukkan bahwa ia memahami apa yang mungkin dan apa yang tidak.
Bagaimana cara menerjemahkannya?
Tetapi bagaimana semua ini dapat dibawa ke perusahaan? Anda perlu memahami bahwa ini akan memakan waktu.
Kita harus mulai dengan orang-orang senior yang bertugas. Mereka memiliki pengalaman dan tahu apa dan bagaimana cara memperbaikinya. Tuan memiliki lebih sedikit masalah: ada akses ke log, dll.
Dianjurkan untuk memulai dalam tim kecil. Jika tim sudah besar, Anda harus membuat yang kecil di dalamnya. Selanjutnya, ketika semuanya mulai bekerja dengan baik, Anda dapat mempermalukan sisanya.
Kesimpulan
Kami lolos ke hal utama. Terlepas dari kenyataan bahwa kami teknisi cinta dengan teknologi, yang paling penting bukanlah produk dan teknologi yang digunakan di perusahaan, tetapi perasaan orang yang bertugas "Saya terlibat dalam proses meningkatkan produk" (atau tugas itu sendiri). Banyak orang mengerti bahwa Anda harus bertugas, tetapi Anda ingin melihat peningkatan. Orang-orang harus sadar bahwa berkat mereka dan perbaikannya, semuanya menjadi lebih baik.
PS
Kami ingin merekomendasikan buku berjudul Drive. Ini adalah buku tentang motivasi orang-orang yang bekerja dalam profesi seperti kita. Motivasi ini terdiri dari tiga komponen utama dan (spoiler) tidak satupun dari mereka adalah uang.
Sudah hari Minggu ini, Baruch dan Leonid akan menyampaikan laporan "#DataDrivenDevOps" di DevOops 2018 di St. Petersburg. Ayo, akan ada banyak hal menarik: inilah laporannya , inilah John Willis , dan di sini ada pesta dengan BoF dan karaoke . Menunggu kamu!