Halo, Habr! Selama sepuluh tahun saya telah mendukung sistem IT Highload. Saya tidak akan menulis di artikel ini tentang masalah konfigurasi nginx agar berfungsi dalam mode 1000+ RPS atau hal-hal teknis lainnya. Saya akan membagikan pengamatan tentang masalah dalam proses yang muncul dalam dukungan dan pengoperasian sistem tersebut.
Pemantauan
Dukungan teknis tidak menunggu sampai aplikasi datang dengan konten "
Mengapa Mengapa ... situs ini mati lagi?". Dukungan satu menit setelah situs mogok seharusnya sudah melihat masalah dan mulai menyelesaikannya.
Tapi situs itu adalah puncak gunung es . Ketersediaannya adalah salah satu yang pertama dimonitor.
Bagaimana dengan situasi ketika sisa-sisa barang dari toko online berhenti datang dari sistem ERP? Atau apakah sistem CRM yang menghitung diskon untuk pelanggan berhenti merespons? Pada saat yang sama, situs tersebut berfungsi. Zabbix bersyarat mendapat 200 tanggapan. Pergeseran yang bertugas tidak menerima pemberitahuan apa pun dari pemantauan dan dengan senang hati memeriksa episode pertama musim baru Game of Thrones.
Seringkali, pemantauan dibatasi hanya dengan mengukur keadaan memori, RAM, dan beban prosesor server. Tetapi jauh lebih penting bagi bisnis untuk mendapatkan ketersediaan produk di situs. Penurunan bersyarat dari satu mesin virtual di cluster akan menyebabkan lalu lintas berhenti mengalir ke sana dan beban di server lain akan meningkat. Perusahaan tidak akan kehilangan uang.
Oleh karena itu, selain memantau parameter teknis sistem operasi pada server, Anda perlu mengonfigurasi metrik bisnis. Metrik yang secara langsung memengaruhi uang. Berbagai interaksi dengan sistem eksternal (CRM, ERP dan lainnya). Jumlah pesanan untuk periode waktu tertentu. Otorisasi klien yang berhasil atau tidak berhasil dan metrik lainnya.
Interaksi dengan sistem eksternal
Situs web atau aplikasi seluler apa pun dengan omset tahunan lebih dari satu miliar rubel berinteraksi dengan sistem eksternal. Mulai dari CRM dan ERP yang disebutkan di atas dan berakhir dengan transfer data penjualan ke sistem Big Data eksternal untuk menganalisis pembelian dan menawarkan kepada pelanggan produk yang pasti akan ia beli (pada kenyataannya, tidak). Setiap sistem tersebut memiliki dukungannya sendiri. Dan seringkali komunikasi dengan sistem ini menyebabkan rasa sakit. Terutama ketika masalahnya bersifat global dan Anda perlu menganalisisnya dalam sistem yang berbeda.
Beberapa sistem memberikan telepon atau telegram ke admin mereka. Di suatu tempat Anda perlu menulis surat kepada manajer atau pergi ke pelacak bug dari sistem eksternal ini. Bahkan dalam konteks satu perusahaan besar, sistem yang berbeda sering bekerja dalam sistem akuntansi aplikasi yang berbeda. Terkadang menjadi tidak mungkin untuk melacak status aplikasi. Anda menerima aplikasi dalam satu Jira bersyarat. Kemudian, di komentar Jira pertama ini, Anda menaruh tautan ke tugas di Jira lain. Di Jira kedua dalam aplikasi, seseorang sudah menulis komentar bahwa
Anda perlu memanggil administrator kondisional Andrei untuk menyelesaikan masalah. Dan sebagainya.
Solusi terbaik untuk masalah ini adalah menciptakan ruang tunggal untuk komunikasi, misalnya di Slack. Undangan untuk itu semua peserta dalam pengoperasian sistem eksternal. Serta pelacak tunggal, agar tidak menggandakan aplikasi. Aplikasi harus dipantau di satu tempat, mulai dari peringatan peringatan hingga menampilkan bug pada produk. Anda akan mengatakan bahwa ini tidak realistis dan secara historis terjadi sehingga kami bekerja di satu pelacak, dan mereka ada di yang lain. Sistem yang berbeda muncul, mereka memiliki tim IT otonom mereka sendiri. Saya setuju dan karena itu masalah perlu dipecahkan dari atas di tingkat CIO atau pemilik produk.
Setiap sistem yang berinteraksi dengan Anda harus menyediakan dukungan sebagai layanan dengan SLA yang jelas untuk menyelesaikan masalah dengan prioritas. Dan tidak ketika administrator bersyarat Andrey memiliki waktu sebentar untuk Anda.
Man - Bottleneck
Apakah semua orang di proyek (atau produk) memiliki orang seperti itu yang kepergiannya berlibur menyebabkan pihak berwenang kram? Ini bisa menjadi insinyur, analis atau pengembang. Lagi pula, hanya seorang insinyur yang tahu kontainer mana yang dipasang pada server mana, bagaimana memuat ulang kontainer jika ada masalah, dan memang ada masalah kompleks yang tidak dapat diselesaikan tanpa itu. Analis adalah satu-satunya yang tahu bagaimana mekanisme kompleks Anda bekerja. Aliran data apa yang digunakan kemana. Pada parameter apa permintaan ke layanan mana, yang akan kami terima jawabannya.
Siapa yang akan dengan cepat memahami mengapa ada kesalahan dalam log dan dengan cepat memperbaiki bug penting di prod? Tentu pengembang yang sama. Ada yang lain, tetapi untuk beberapa alasan hanya dia yang mengerti bagaimana berbagai modul sistem diatur.
Akar masalah ini adalah kurangnya dokumentasi . Lagi pula, jika semua layanan sistem Anda dijelaskan, maka akan mungkin untuk mengatasi masalah tanpa analis. Jika devops memilih beberapa hari dari jadwalnya yang sibuk dan menggambarkan semua server, layanan, dan instruksi untuk memecahkan masalah yang khas, maka masalah yang tidak ada dapat diselesaikan tanpa itu. Tidak perlu berlibur untuk segera menyelesaikan bir Anda di pantai dan mencari wi-fi untuk menyelesaikan masalah.
Kompetensi dan tanggung jawab staf pendukung
Pada proyek besar, perusahaan tidak berhemat pada gaji kepada pengembang. Mereka memburu perantara atau manula mahal dari proyek serupa. Dengan dukungan, situasinya sedikit berbeda. Mereka berusaha dengan segala cara yang mungkin untuk mengurangi biaya ini. Perusahaan-perusahaan mempekerjakan enikeyshikov berbiaya rendah kemarin dan dengan berani berperang. Strategi semacam itu dimungkinkan ketika datang ke situs kartu nama beberapa pabrik di Zelenograd.
Jika kita berbicara tentang toko online besar, maka setiap jam downtime biayanya lebih dari gaji bulanan seorang administrator-enikeik. Ambil untuk titik awal 1 miliar rubel omset tahunan. Ini adalah omset minimum toko online mana pun dari peringkat
TOP-100 untuk tahun 2018 . Bagilah jumlah ini dengan jumlah jam per tahun dan dapatkan lebih dari 100.000 rubel kerugian bersih. Dan jika Anda tidak menghitung jam malam, maka Anda dapat dengan aman menggandakan jumlahnya.
Tetapi uang bukanlah yang utama, bukan? (tidak, tentu saja hal utama) Masih ada kerugian reputasi. Jam jatuhnya toko online terkenal dapat menyebabkan gelombang review di jejaring sosial dan publikasi di media tematik. Dan percakapan teman-teman di dapur dengan gaya "Jangan membeli apa pun di sana, situs mereka selalu turun" tidak cocok untuk pengukuran sama sekali.
Sekarang bertanggung jawab. Dalam praktik saya, ada kasus di mana administrator yang bertugas tidak merespons pada waktunya untuk memberi tahu sistem pemantauan tentang tidak dapat diaksesnya situs. Pada musim panas Jumat malam yang menyenangkan, situs salah satu toko online terkenal di Moskow berbaring diam. Pada hari Sabtu pagi, produk dari situs ini tidak mengerti mengapa situs tersebut tidak terbuka, dan ada keheningan dalam obrolan dukungan dan peringatan mendesak di Slack. Kesalahan seperti itu menghabiskan biaya enam digit, dan petugas jaga ini bekerja.
Tanggung jawab adalah keterampilan yang sulit untuk dikembangkan. Seseorang bisa memilikinya atau tidak. Karena itu, dalam wawancara, saya mencoba mengidentifikasi kehadirannya dengan berbagai pertanyaan yang secara tidak langsung menunjukkan apakah seseorang terbiasa mengambil tanggung jawab. Jika seseorang menjawab bahwa dia memilih universitas karena orang tuanya mengatakannya atau mengubah pekerjaannya karena istrinya mengatakan bahwa dia tidak menerima banyak, maka lebih baik untuk tidak terlibat dengan orang-orang seperti itu.
Interaksi dengan tim pengembangan
Ketika pengguna mengalami masalah sederhana pada produk selama operasi, dukungan menyelesaikannya sendiri. Mencoba mereproduksi masalah, menganalisis log, dan sebagainya. Tetapi apa yang harus dilakukan ketika sebuah bug muncul pada prod? Dalam hal ini, dukungan memulai tugas untuk pengembang, dan di sini kesenangan dimulai.
Pengembang terus kelebihan beban. Mereka menciptakan fitur baru. Perbaiki bug dengan pelajaran penjualan, katakan bukan yang paling menarik. Tenggat waktu untuk menyelesaikan sprint berikutnya sudah aktif. Dan kemudian orang-orang yang tidak menyenangkan datang dari dukungan dan berkata: "Segera tinggalkan semuanya, kami memiliki masalah." Prioritas tugas tersebut minimal. Terutama ketika masalahnya bukan yang paling kritis dan fungsi utama situs berfungsi, dan ketika manajer rilis tidak berjalan dengan mata menonjol dan tidak menulis: "Mendesak untuk membawa tugas ini ke rilis berikutnya atau perbaikan terbaru."
Tugas dengan prioritas normal atau rendah berubah dari rilis ke rilis. Untuk pertanyaan "Kapan tugas akan selesai?" Anda akan menerima jawaban dengan gaya: "Maaf, sekarang ada banyak tugas, meminta pimpinan tim atau manajer rilis."
Masalah pada produk memiliki prioritas lebih tinggi daripada membuat fitur baru. Ulasan buruk tidak akan membuat Anda menunggu jika pengguna terus-menerus menemukan bug. Sulit untuk mengembalikan reputasi yang rusak.
Masalah interaksi antara pengembangan dan dukungan diselesaikan oleh DevOps. Singkatan ini sering digunakan sebagai orang tertentu yang membantu menciptakan lingkungan pengujian untuk pengembangan, membangun jaringan pipa CI \ CD dan dengan cepat menampilkan kode yang diuji dalam produksi. DevOps adalah pendekatan pengembangan perangkat lunak ketika semua peserta dalam proses berinteraksi erat satu sama lain dan membantu untuk dengan cepat membuat dan memperbarui produk dan layanan perangkat lunak. Maksud saya analis, pengembang, penguji, dan dukungan.
Dukungan dan pengembangan dalam pendekatan ini bukanlah departemen yang berbeda dengan tujuan dan sasarannya. Pengembangan terlibat dalam operasi dan sebaliknya. Ungkapan terkenal tim terdistribusi: "Masalahnya bukan di pihak saya" tidak begitu sering terlihat di ruang obrolan, dan pengguna akhir menjadi sedikit lebih bahagia.