Hello, Habr! Saya telah menyokong sistem IT Highload selama sepuluh tahun. Saya tidak akan menulis dalam artikel ini tentang masalah menyediakan nginx untuk berfungsi dalam mod 1000+ RPS atau perkara teknikal lain. Saya akan berkongsi pemerhatian saya tentang masalah dalam proses yang timbul dalam sokongan dan operasi sistem tersebut.
Pemantauan
Sokongan teknikal tidak menunggu sehingga permintaan tiba dengan kandungan "Apa Mengapa... tapak tidak berfungsi lagi?" Dalam masa seminit selepas tapak ranap, sokongan sepatutnya sudah melihat masalah dan mula menyelesaikannya. Tetapi tapak itu adalah puncak gunung ais. Ketersediaannya adalah salah satu yang pertama dipantau.
Apa yang perlu dilakukan dengan keadaan apabila baki barangan kedai dalam talian tidak lagi tiba dari sistem ERP? Atau adakah sistem CRM yang mengira diskaun untuk pelanggan telah berhenti bertindak balas? Tapak itu nampaknya berfungsi. Zabbix bersyarat menerima 200 responsnya. Anjakan tugas tidak menerima sebarang pemberitahuan daripada pemantauan dan sedang menonton episod pertama musim baharu Game of Thrones.
Pemantauan selalunya terhad kepada hanya mengukur keadaan memori, RAM dan beban pemproses pelayan. Tetapi untuk perniagaan adalah lebih penting untuk mendapatkan ketersediaan produk di tapak web. Kegagalan bersyarat satu mesin maya dalam kluster akan membawa kepada fakta bahawa trafik akan berhenti pergi ke sana dan beban pada pelayan lain akan meningkat. Syarikat tidak akan kehilangan wang.
Oleh itu, selain memantau parameter teknikal sistem pengendalian pada pelayan, anda perlu mengkonfigurasi metrik perniagaan. Metrik yang mempengaruhi wang secara langsung. Pelbagai interaksi dengan sistem luaran (CRM, ERP dan lain-lain). Bilangan pesanan untuk tempoh masa tertentu. Keizinan pelanggan yang berjaya atau tidak berjaya dan metrik lain.
Interaksi dengan sistem luaran
Mana-mana laman web atau aplikasi mudah alih dengan perolehan tahunan lebih daripada satu bilion rubel berinteraksi dengan sistem luaran. Bermula dari CRM dan ERP yang disebutkan di atas dan berakhir dengan pemindahan data jualan kepada sistem Data Besar luaran untuk menganalisis pembelian dan menawarkan pelanggan produk yang dia pasti akan beli (sebenarnya, tidak). Setiap sistem sedemikian mempunyai sokongan sendiri. Dan selalunya komunikasi dengan sistem ini menyebabkan kesakitan. Terutama apabila masalahnya adalah global dan anda perlu menganalisisnya dalam sistem yang berbeza.
Sesetengah sistem menyediakan nombor telefon atau telegram untuk pentadbir mereka. Di suatu tempat anda perlu menulis surat kepada pengurus atau pergi ke penjejak pepijat sistem luaran ini. Walaupun dalam konteks satu syarikat besar, sistem yang berbeza sering beroperasi dalam sistem perakaunan aplikasi yang berbeza. Kadang-kadang menjadi mustahil untuk menjejaki status aplikasi. Anda menerima permintaan dalam satu Jira bersyarat. Kemudian dalam komen Jira pertama ini anda meletakkan pautan kepada isu itu di Jira lain. Dalam Jira kedua dalam permohonan itu, seseorang sudah menulis komen itu anda perlu menghubungi pentadbir bersyarat Andrey untuk menyelesaikan isu tersebut. Dan sebagainya.
Penyelesaian terbaik untuk masalah ini ialah mewujudkan satu ruang untuk komunikasi, contohnya dalam Slack. Menjemput semua peserta dalam proses pengendalian sistem luaran untuk menyertai. Dan juga penjejak tunggal supaya tidak menduplikasi aplikasi. Aplikasi harus dijejaki di satu tempat, daripada pemantauan pemberitahuan kepada output penyelesaian pepijat pada masa hadapan. Anda akan mengatakan bahawa ini tidak realistik dan secara sejarah berlaku bahawa kami bekerja dalam satu penjejak, dan mereka berfungsi dalam penjejak yang lain. Sistem yang berbeza muncul, mereka mempunyai pasukan IT autonomi mereka sendiri. Saya bersetuju, dan oleh itu masalah itu perlu diselesaikan dari atas di peringkat CIO atau pemilik produk.
Setiap sistem yang anda berinteraksi harus memberikan sokongan sebagai perkhidmatan dengan SLA yang jelas untuk menyelesaikan isu mengikut keutamaan. Dan bukan apabila pentadbir bersyarat Andrey mempunyai satu minit untuk anda.
Lelaki Bottleneck
Adakah setiap orang dalam projek (atau produk) mempunyai seseorang yang pergi bercuti menyebabkan sawan di kalangan atasan mereka? Ini boleh menjadi jurutera, penganalisis atau pembangun devops. Lagipun, hanya jurutera devops yang tahu pelayan mana yang mempunyai bekas yang dipasang, bagaimana untuk but semula bekas sekiranya berlaku masalah, dan secara amnya, sebarang masalah kompleks tidak dapat diselesaikan tanpa dia. Penganalisis adalah satu-satunya yang tahu bagaimana mekanisme kompleks anda berfungsi. Strim data mana pergi ke mana. Di bawah parameter permintaan kepada perkhidmatan yang mana, yang mana kami akan menerima respons.
Siapa yang akan memahami dengan cepat mengapa terdapat ralat dalam log dan segera membetulkan pepijat kritikal dalam produk? Sudah tentu pembangun yang sama. Terdapat yang lain, tetapi atas sebab tertentu hanya dia yang memahami bagaimana modul sistem yang berbeza berfungsi.
Punca masalah ini adalah kekurangan dokumentasi. Lagipun, jika semua perkhidmatan sistem anda diterangkan, maka ia mungkin untuk menangani masalah itu tanpa penganalisis. Jika devops mengambil masa beberapa hari daripada jadual sibuknya dan menerangkan semua pelayan, perkhidmatan dan arahan untuk menyelesaikan masalah biasa, maka masalah semasa ketiadaannya boleh diselesaikan tanpa dia. Anda tidak perlu menghabiskan bir anda dengan cepat di pantai semasa bercuti dan mencari wi-fi untuk menyelesaikan masalah.
Kecekapan dan tanggungjawab kakitangan sokongan
Dalam projek besar, syarikat tidak berjimat dengan gaji pemaju. Mereka sedang mencari orang tengah atau senior yang mahal dari projek yang serupa. Dengan sokongan keadaan adalah sedikit berbeza. Mereka cuba mengurangkan kos ini dalam setiap cara yang mungkin. Syarikat-syarikat mengupah pekerja Enikey yang murah semalam dan berani pergi berperang. Strategi ini boleh dilakukan jika kita bercakap tentang laman web kad perniagaan kilang di Zelenograd.
Jika kita bercakap tentang kedai dalam talian yang besar, maka setiap jam masa henti kos lebih daripada gaji bulanan pentadbir Enikey. Mari kita ambil 1 bilion rubel perolehan tahunan sebagai titik permulaan. Ini ialah perolehan minimum mana-mana kedai dalam talian daripada penarafan . Bahagikan jumlah ini dengan bilangan jam setahun dan dapatkan lebih daripada 100 rubel kerugian bersih. Dan jika anda tidak mengira waktu malam, anda boleh menggandakan jumlahnya dengan selamat.
Tetapi wang bukanlah perkara utama, bukan? (tidak, sudah tentu perkara utama) Terdapat juga kerugian reputasi. Kejatuhan kedai dalam talian yang terkenal boleh menyebabkan gelombang ulasan pada rangkaian sosial dan penerbitan dalam media tematik. Dan perbualan rakan-rakan di dapur dalam gaya "Jangan beli apa-apa di sana, laman web mereka sentiasa tidak berfungsi" tidak boleh diukur sama sekali.
Sekarang kepada tanggungjawab. Dalam amalan saya, terdapat kes apabila pentadbir yang bertugas tidak bertindak balas tepat pada masanya kepada pemberitahuan daripada sistem pemantauan tentang ketiadaan tapak. Pada petang Jumaat musim panas yang menyenangkan, laman web kedai dalam talian yang terkenal di Moscow terletak dengan tenang. Pada pagi Sabtu, pengurus produk tapak ini tidak memahami mengapa tapak itu tidak dibuka, dan terdapat senyap dalam sembang sokongan dan pemberitahuan segera dalam Slack. Kesilapan sebegitu menyebabkan kami kerugian enam angka, dan pegawai bertugas ini tugasnya.
Tanggungjawab adalah kemahiran yang sukar untuk dikembangkan. Sama ada seseorang mempunyainya atau tidak. Oleh itu, semasa temu bual, saya cuba mengenal pasti kehadirannya dengan pelbagai persoalan yang secara tidak langsung menunjukkan sama ada seseorang itu sudah biasa memikul tanggungjawab. Jika seseorang menjawab bahawa dia memilih universiti kerana ibu bapanya berkata demikian atau bertukar pekerjaan kerana isterinya mengatakan bahawa dia tidak mencukupi, maka lebih baik tidak terlibat dengan orang sedemikian.
Interaksi dengan pasukan pembangunan
Apabila pengguna menghadapi masalah mudah dengan produk semasa operasi, sokongan menyelesaikannya sendiri. Cuba untuk menghasilkan semula masalah, menganalisis log, dan sebagainya. Tetapi apa yang perlu dilakukan apabila pepijat muncul dalam produk? Dalam kes ini, sokongan memberikan tugas kepada pembangun dan di sinilah keseronokan bermula.
Pemaju sentiasa terlebih beban. Mereka mencipta ciri baharu. Membetulkan pepijat dengan jualan bukanlah aktiviti yang paling menarik. Tarikh akhir semakin hampir untuk melengkapkan pecut seterusnya. Dan kemudian orang yang tidak menyenangkan dari sokongan datang dan berkata: "Hentikan segala-galanya dengan segera, kami mempunyai masalah." Keutamaan tugas sedemikian adalah minimum. Terutamanya apabila masalahnya bukanlah yang paling kritikal dan fungsi utama tapak berfungsi, dan apabila pengurus keluaran tidak berlari dengan mata yang membonjol dan menulis: "Tambahkan tugas ini dengan segera pada keluaran atau pembaikan terbaru."
Isu dengan keutamaan biasa atau rendah dialihkan dari keluaran ke keluaran. Kepada soalan "Bilakah tugas itu akan selesai?" anda akan menerima jawapan dalam gaya: "Maaf, terdapat banyak tugas sekarang, tanya ketua pasukan anda atau pengurus pelepasan."
Masalah produktiviti mengambil keutamaan yang lebih tinggi daripada mencipta ciri baharu. Ulasan buruk tidak akan lama datang jika pengguna sentiasa terjumpa pepijat. Reputasi yang rosak sukar dipulihkan.
Isu interaksi antara pembangunan dan sokongan diselesaikan oleh DevOps. Singkatan ini sering digunakan dalam bentuk orang tertentu yang membantu mencipta persekitaran ujian untuk pembangunan, membina saluran paip CICD dan dengan cepat membawa kod yang diuji ke dalam pengeluaran. DevOps ialah pendekatan kepada pembangunan perisian apabila semua peserta dalam proses berinteraksi rapat antara satu sama lain dan membantu mencipta dan mengemas kini produk dan perkhidmatan perisian dengan cepat. Maksud saya penganalisis, pembangun, penguji dan sokongan.
Dalam pendekatan ini, sokongan dan pembangunan bukanlah jabatan yang berbeza dengan matlamat dan objektif mereka sendiri. Pembangunan terlibat dalam operasi dan sebaliknya. Frasa terkenal pasukan yang diedarkan: "Masalahnya bukan di pihak saya" tidak lagi muncul dalam sembang begitu kerap, dan pengguna akhir menjadi lebih gembira.
Sumber: www.habr.com