Halo, Habr! Saya telah mendukung sistem IT Highload selama sepuluh tahun. Saya tidak akan menulis di artikel ini tentang masalah setting nginx agar bekerja di mode 1000+ RPS atau hal teknis lainnya. Saya akan berbagi pengamatan saya tentang permasalahan dalam proses yang muncul dalam dukungan dan pengoperasian sistem tersebut.
Pemantauan
Dukungan teknis tidak menunggu hingga permintaan datang dengan konten “Apa Mengapa... situs tidak berfungsi lagi?” Dalam satu menit setelah situs mogok, dukungan seharusnya sudah melihat masalahnya dan mulai menyelesaikannya. Namun situs tersebut adalah puncak gunung es. Ketersediaannya adalah salah satu yang pertama dipantau.
Apa yang harus dilakukan jika sisa barang toko online tidak lagi masuk dari sistem ERP? Atau apakah sistem CRM yang menghitung diskon untuk klien berhenti merespons? Situs ini tampaknya berfungsi. Zabbix bersyarat menerima 200 tanggapannya. Pergeseran tugas belum menerima pemberitahuan apa pun dari pemantauan dan dengan senang hati menonton episode pertama musim baru Game of Thrones.
Pemantauan seringkali terbatas hanya pada pengukuran keadaan memori, RAM dan beban prosesor server. Namun bagi bisnis, jauh lebih penting untuk mendapatkan ketersediaan produk di website. Kegagalan bersyarat dari satu mesin virtual di cluster akan menyebabkan fakta bahwa lalu lintas akan berhenti menuju ke sana dan beban pada server lain akan meningkat. Perusahaan tidak akan merugi.
Oleh karena itu, selain memantau parameter teknis sistem operasi di server, Anda perlu mengonfigurasi metrik bisnis. Metrik yang secara langsung mempengaruhi uang. Berbagai interaksi dengan sistem eksternal (CRM, ERP dan lain-lain). Jumlah pesanan untuk jangka 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 diakhiri dengan transfer data penjualan ke sistem Big Data eksternal untuk menganalisis pembelian dan menawarkan kepada klien produk yang pasti akan dia beli (sebenarnya tidak). Masing-masing sistem tersebut memiliki dukungannya sendiri. Dan seringkali komunikasi dengan sistem ini menimbulkan rasa sakit. Terutama ketika masalahnya bersifat global dan Anda perlu menganalisisnya dalam sistem yang berbeda.
Beberapa sistem menyediakan nomor telepon atau telegram untuk administratornya. Di suatu tempat Anda perlu menulis surat kepada manajer atau pergi ke pelacak bug sistem eksternal ini. Bahkan dalam konteks satu perusahaan besar, sistem yang berbeda sering kali beroperasi dalam sistem akuntansi aplikasi yang berbeda. Terkadang menjadi tidak mungkin untuk melacak status suatu aplikasi. Anda menerima permintaan dalam satu Jira bersyarat. Kemudian di komentar Jira pertama ini Anda memasang link isu tersebut di Jira yang lain. Di Jira kedua di aplikasi, sudah ada yang menulis komentar itu Anda perlu menghubungi admin bersyarat Andrey untuk menyelesaikan masalah tersebut. Dan seterusnya.
Solusi terbaik untuk masalah ini adalah dengan menciptakan ruang komunikasi tunggal, misalnya di Slack. Mengundang semua peserta dalam proses pengoperasian sistem eksternal untuk bergabung. Dan juga pelacak tunggal agar tidak menduplikasi aplikasi. Aplikasi harus dilacak di satu tempat, mulai dari memantau pemberitahuan hingga keluaran solusi bug di masa mendatang. Anda akan mengatakan bahwa ini tidak realistis dan secara historis kami bekerja di satu pelacak, dan mereka bekerja di pelacak lain. Sistem yang berbeda muncul, mereka memiliki tim TI otonom mereka sendiri. Saya setuju, dan oleh karena itu masalahnya perlu diselesaikan dari atas di tingkat CIO atau pemilik produk.
Setiap sistem yang berinteraksi dengan Anda harus memberikan dukungan sebagai layanan dengan SLA yang jelas untuk menyelesaikan masalah berdasarkan prioritas. Dan tidak ketika admin bersyarat Andrey punya waktu sebentar untuk Anda.
Manusia Kemacetan
Apakah setiap orang dalam suatu proyek (atau produk) memiliki seseorang yang pergi berlibur menyebabkan keributan di kalangan atasannya? Ini bisa berupa insinyur pengembang, analis, atau pengembang. Lagi pula, hanya insinyur devops yang tahu server mana yang memasang container apa, cara me-reboot container jika ada masalah, dan secara umum, masalah rumit apa pun tidak dapat diselesaikan tanpa dia. Analis adalah satu-satunya yang mengetahui cara kerja mekanisme kompleks Anda. Aliran data mana yang menuju ke mana. Berdasarkan parameter permintaan apa, layanan apa, respons mana yang akan kami terima.
Siapa yang akan dengan cepat memahami mengapa ada kesalahan dalam log dan segera memperbaiki bug kritis pada produk? Tentu saja pengembangnya sama. Ada yang lain, tapi entah kenapa hanya dia yang mengerti cara kerja berbagai modul sistem.
Akar permasalahan ini adalah kurangnya dokumentasi. Lagi pula, jika semua layanan sistem Anda dijelaskan, maka masalah tersebut dapat ditangani tanpa seorang analis. Jika devops meluangkan beberapa hari dari jadwal sibuknya dan menjelaskan semua server, layanan, dan instruksi untuk menyelesaikan masalah umum, maka masalah saat dia tidak ada dapat diselesaikan tanpa dia. Anda tidak perlu cepat-cepat menghabiskan bir di pantai saat berlibur dan mencari wi-fi untuk mengatasi masalah tersebut.
Kompetensi dan tanggung jawab staf pendukung
Pada proyek-proyek besar, perusahaan tidak berhemat pada gaji pengembang. Mereka mencari perantara atau senior yang mahal dari proyek serupa. Dengan dukungan, situasinya sedikit berbeda. Mereka berusaha mengurangi biaya ini dengan segala cara yang memungkinkan. Perusahaan mempekerjakan pekerja Enikey yang murah dan berani berperang. Strategi ini dimungkinkan jika kita berbicara tentang situs web kartu nama sebuah pabrik di Zelenograd.
Jika kita berbicara tentang toko online besar, maka setiap jam waktu henti lebih mahal daripada gaji bulanan seorang administrator Enikey. Mari kita ambil omset tahunan sebesar 1 miliar rubel sebagai titik awal. Ini adalah omset minimum toko online mana pun dari peringkat tersebut . Bagilah jumlah ini dengan jumlah jam per tahun dan dapatkan kerugian bersih lebih dari 100 rubel. Dan jika Anda tidak menghitung jam malam, Anda dapat menggandakan jumlahnya dengan aman.
Tapi uang bukanlah yang utama, bukan? (tidak, tentu saja yang utama) Ada juga kerugian reputasi. Jatuhnya toko online ternama dapat menimbulkan gelombang ulasan di jejaring sosial dan publikasi di media tematik. Dan perbincangan teman-teman di dapur dengan gaya “Jangan beli apa pun di sana, websitenya selalu down” tidak bisa diukur sama sekali.
Sekarang tanggung jawab. Dalam praktik saya, ada kasus ketika administrator yang bertugas tidak merespons pemberitahuan dari sistem pemantauan tentang tidak tersedianya situs tepat waktu. Pada suatu Jumat malam musim panas yang menyenangkan, situs web toko online terkenal di Moskow tergeletak dengan tenang. Pada hari Sabtu pagi, manajer produk situs ini tidak mengerti mengapa situs tersebut tidak terbuka, dan ada keheningan dalam obrolan dukungan dan pemberitahuan mendesak di Slack. Kesalahan seperti itu membuat kami kehilangan sejumlah uang, dan petugas jaga ini kehilangan pekerjaannya.
Tanggung jawab adalah keterampilan yang sulit untuk dikembangkan. Entah seseorang memilikinya atau tidak. Oleh 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 pendapat orang tuanya atau berganti pekerjaan karena istrinya mengatakan bahwa penghasilannya tidak cukup, maka lebih baik tidak terlibat dengan orang-orang tersebut.
Interaksi dengan tim pengembangan
Ketika pengguna mengalami masalah sederhana dengan suatu produk selama pengoperasian, dukungan menyelesaikannya sendiri. Mencoba mereproduksi masalah, menganalisis log, dan seterusnya. Namun apa yang harus dilakukan jika muncul bug pada produk? Dalam hal ini, dukungan memberikan tugas kepada pengembang dan di sinilah kesenangan dimulai.
Pengembang terus-menerus kelebihan beban. Mereka menciptakan fitur-fitur baru. Memperbaiki bug dalam penjualan bukanlah aktivitas yang paling menarik. Tenggat waktu semakin dekat untuk menyelesaikan sprint berikutnya. Dan kemudian orang-orang yang tidak menyenangkan dari dukungan datang dan berkata: "Segera hentikan semuanya, kita punya masalah." Prioritas tugas-tugas tersebut minimal. Terutama ketika masalahnya bukan yang paling kritis dan fungsi utama situs berfungsi, dan ketika manajer rilis tidak berjalan dengan mata melotot dan menulis: “Segera tambahkan tugas ini ke rilis atau perbaikan terbaru berikutnya.”
Masalah dengan prioritas normal atau rendah dipindahkan dari satu rilis ke rilis lainnya. Untuk pertanyaan “Kapan tugas tersebut akan selesai?” Anda akan menerima jawaban seperti: “Maaf, ada banyak tugas saat ini, tanyakan kepada pimpinan tim atau manajer rilis Anda.”
Masalah produktivitas mendapat prioritas lebih tinggi dibandingkan pembuatan fitur baru. Ulasan buruk tidak akan lama lagi jika pengguna terus-menerus menemukan bug. Reputasi yang rusak sulit dipulihkan.
Masalah interaksi antara pengembangan dan dukungan diselesaikan oleh DevOps. Singkatan ini sering digunakan dalam bentuk orang tertentu yang membantu menciptakan lingkungan pengujian untuk pengembangan, membangun saluran CICD, dan dengan cepat membawa kode yang diuji ke dalam produksi. DevOps adalah pendekatan pengembangan perangkat lunak ketika semua peserta dalam proses berinteraksi erat satu sama lain dan membantu membuat dan memperbarui produk dan layanan perangkat lunak dengan cepat. Maksud saya analis, pengembang, penguji, dan dukungan.
Dalam pendekatan ini, dukungan dan pengembangan bukanlah departemen yang berbeda dengan tujuan dan sasarannya masing-masing. Pembangunan terlibat dalam operasi dan sebaliknya. Ungkapan terkenal dari tim terdistribusi: “Masalahnya bukan di pihak saya” tidak lagi sering muncul dalam obrolan, dan pengguna akhir menjadi sedikit lebih bahagia.
Sumber: www.habr.com