Hai, Habr! Saya telah menyokong sistem IT Highload selama sepuluh tahun. Dalam artikel ini, saya tidak akan membincangkan cabaran mengkonfigurasi Nginx untuk mengendalikan 1000+ RPS atau isu teknikal lain. Saya akan berkongsi pemerhatian saya tentang isu proses yang timbul dalam menyokong dan mengendalikan sistem sedemikian.
Pemantauan
Sokongan teknikal tidak menunggu tiket tiba dengan bertanya, "Apa... adakah tapak itu turun semula?" Sokongan akan melihat masalah dalam masa seminit selepas tapak itu turun dan mula membetulkannya. Tetapi laman web adalah puncak gunung aisKetersediaannya adalah salah satu yang pertama dipantau.
Apakah yang perlu dilakukan apabila inventori kedai dalam talian berhenti daripada sistem ERP? Atau sistem CRM yang mengira diskaun pelanggan telah berhenti bertindak balas? Laman web itu, bagaimanapun, nampaknya berfungsi. Zabbix, sebagai contoh, menerima 200 responsnya. Syif bertugas tidak menerima sebarang pemberitahuan daripada pemantauan dan sedang menonton episod pertama musim baharu Game of Thrones.
Selalunya, pemantauan terhad kepada mengukur keadaan memori, RAM dan beban pemproses. pelayan. Tetapi untuk perniagaan, memastikan ketersediaan produk di tapak web adalah jauh lebih penting. Kegagalan mesin maya tunggal dalam gugusan akan mengakibatkan trafik berhenti dan meningkatkan beban pada pelayan lain. Syarikat tidak akan kehilangan wang.
Oleh itu, selain memantau parameter teknikal sistem pengendalian pada pelayan, adalah perlu untuk mengkonfigurasi metrik perniagaan. Metrik ini secara langsung memberi kesan kepada hasil, seperti pelbagai interaksi dengan sistem luaran (CRM, ERP dan lain-lain), bilangan pesanan dalam tempoh masa tertentu, kebenaran pelanggan yang berjaya atau tidak berjaya dan metrik lain.
Interaksi dengan sistem luaran
Mana-mana tapak web atau aplikasi mudah alih dengan perolehan tahunan melebihi satu bilion rubel berinteraksi dengan sistem luaran. Ini terdiri daripada sistem CRM dan ERP yang disebutkan di atas kepada pemindahan data jualan kepada sistem Data Besar luaran untuk menganalisis pembelian dan menawarkan produk kepada pelanggan yang mereka pasti akan beli (atau, sebenarnya, tidak akan). Setiap sistem ini mempunyai sistem sokongan tersendiri. Dan berkomunikasi dengan sistem ini selalunya menyakitkan, terutamanya apabila masalahnya adalah global dan memerlukan analisis merentas berbilang sistem.
Sesetengah sistem menyediakan nombor telefon pentadbir mereka atau akaun Telegram. Yang lain memerlukan menghantar e-mel kepada pengurus atau mengakses penjejak pepijat sistem luaran ini. Walaupun dalam satu syarikat besar, sistem yang berbeza sering beroperasi dalam sistem pengurusan tiket yang berbeza. Menjejak status tiket kadangkala mustahil. Anda menerima tiket dalam satu Jira. Kemudian, dalam ulasan dalam Jira pertama itu, anda menambah pautan ke tugasan dalam Jira lain. Dalam Jira kedua, seseorang sudah mengulas tiket, berkata Anda perlu menghubungi pentadbir hipotesis Andrey untuk menyelesaikan isu tersebut. Dan sebagainya.
Penyelesaian optimum untuk masalah ini adalah dengan mencipta ruang komunikasi tunggal, seperti Slack. Jemput semua orang yang terlibat dalam pengendalian sistem luaran kepadanya. Juga, buat penjejak tunggal untuk mengelakkan tiket pendua. Tiket harus dijejaki di satu tempat, daripada pemantauan pemberitahuan kepada menyelesaikan pepijat dalam pengeluaran. Anda mungkin mengatakan bahawa ini adalah tidak realistik dan bahawa kita bekerja dalam satu penjejak dan ia hanya berfungsi dalam satu penjejak yang lain. Sistem yang berbeza muncul, masing-masing dengan pasukan IT autonominya sendiri. Saya bersetuju, dan oleh itu masalah ini perlu ditangani dari atas, di peringkat CIO atau pemilik produk.
Setiap sistem yang anda berinteraksi harus menyediakan sokongan sebagai perkhidmatan dengan SLA yang jelas untuk penyelesaian masalah yang diutamakan. Bukan setakat bila-bila masa admin Andrey ada masa.
Lelaki bottleneck
Adakah setiap projek (atau produk) mempunyai satu orang yang percutiannya menyebabkan pengurusan menjadi kecoh? Ia boleh menjadi jurutera, penganalisis atau pembangun DevOps. Lagipun, hanya jurutera DevOps yang tahu bekas yang dipasang pada pelayan mana, cara but semula bekas sekiranya berlaku masalah, dan, sebenarnya, sebarang masalah kompleks tidak boleh diselesaikan tanpanya. Penganalisis adalah satu-satunya yang mengetahui cara sistem kompleks anda berfungsi. Data mana yang mengalir ke mana. Yang mana meminta perkhidmatan mana yang memerlukan parameter dan respons yang akan kami terima.
Siapa yang boleh mengetahui dengan cepat mengapa terdapat ralat dalam log dan segera membetulkan pepijat kritikal dalam pengeluaran? Pemaju yang sama, sudah tentu. Terdapat yang lain, tetapi atas sebab tertentu, hanya mereka yang memahami bagaimana pelbagai modul sistem berfungsi.
Punca masalah ini adalah kekurangan dokumentasi.Lagipun, jika semua perkhidmatan sistem anda diterangkan, anda boleh menyelesaikan masalah tanpa penganalisis. Jika devops mengambil masa beberapa hari daripada jadual sibuk mereka untuk menerangkan semua pelayan, perkhidmatan dan arahan untuk menyelesaikan isu biasa, masalah itu boleh diselesaikan tanpanya. Tidak perlu menghabiskan bir anda dengan cepat di pantai semasa bercuti dan mencari Wi-Fi untuk menyelesaikan masalah.
Kecekapan dan tanggungjawab kakitangan sokongan
Pada projek utama, syarikat tidak berhemat pada gaji pemaju. Mereka merekrut orang tengah atau senior yang mahal dari projek yang sama. Keadaan dengan sokongan agak berbeza. Mereka cuba mengurangkan kos ini dalam setiap cara yang mungkin. Syarikat mengupah bekas pakar IT yang murah dan pergi bersemuka. Strategi ini boleh dilaksanakan jika kita bercakap tentang tapak web untuk kilang di Zelenograd, sebagai contoh.
Jika kita bercakap tentang kedai dalam talian yang besar, setiap jam masa henti memerlukan kos lebih daripada gaji bulanan untuk pentadbir meja bantuan. Mari kita ambil 1 bilion rubel dalam perolehan tahunan sebagai titik permulaan. Ini adalah perolehan minimum untuk mana-mana kedai dalam talian dalam ranking. Bahagikan jumlah ini dengan bilangan jam setahun, dan kami mendapat kerugian bersih lebih 100,000 rubel. Dan jika kita mengecualikan waktu malam, kita boleh menggandakan jumlah itu dengan mudah.
Tetapi wang bukanlah perkara utama, bukan? (Tidak, sudah tentu ia adalah perkara utama.) Terdapat juga kerugian reputasi. Masa kejatuhan kedai dalam talian yang terkenal boleh mencetuskan gelombang reaksi media sosial dan penerbitan dalam media khusus industri. Dan perbualan antara rakan-rakan di dapur sepanjang baris "Jangan beli apa-apa dari sana, laman web mereka sentiasa dimatikan" sememangnya tidak dapat dikira.
Sekarang, kepada tanggungjawab. Saya mempunyai kes di mana pentadbir yang bertugas gagal bertindak balas dengan segera kepada amaran sistem pemantauan tapak tentang tapak web yang tidak berfungsi. Ia adalah petang Jumaat musim panas yang menyenangkan, dan laman web kedai dalam talian Moscow yang terkenal sunyi. Menjelang pagi Sabtu, pengurus produk untuk tapak web itu tidak dapat mengetahui sebab ia tidak dimuatkan, dan sembang sokongan serta pemberitahuan segera dalam Slack senyap. Kesilapan ini merugikan kami enam angka, dan tugas pentadbir.
Tanggungjawab adalah kemahiran yang sukar untuk dikembangkan. Seseorang sama ada mempunyai atau tidak. Sebab itu saya cuba mengenal pastinya semasa temu bual dengan pelbagai soalan yang secara tidak langsung mendedahkan sama ada seseorang itu sudah biasa memikul tanggungjawab. Jika seseorang mengatakan bahawa mereka memilih kolej kerana ibu bapa mereka menyuruh mereka atau menukar pekerjaan kerana isteri mereka mengatakan mereka tidak mencukupi, lebih baik jangan terlibat dengan mereka.
Interaksi dengan pasukan pembangunan
Apabila pengguna menghadapi isu mudah semasa pengeluaran, sokongan menyelesaikannya secara bebas. Mereka cuba menghasilkan semula masalah, menganalisis log, dan sebagainya. Tetapi apa yang berlaku apabila pepijat muncul dalam pengeluaran? Dalam kes ini, sokongan memberikan tugas kepada pembangun, dan di situlah keseronokan bermula.
Pemaju sentiasa terlebih beban. Mereka sibuk mencipta ciri baharu. Membaiki pepijat dalam pengeluaran bukanlah perkara yang paling menarik untuk dilakukan. Tarikh akhir untuk melengkapkan pecut seterusnya semakin hampir. Dan kemudian orang jahat dari sokongan itu muncul dan berkata, "Lepaskan semuanya dengan segera, kami menghadapi masalah." Tugas-tugas ini adalah keutamaan yang paling rendah. Terutama apabila masalahnya tidak kritikal dan kefungsian teras tapak berfungsi, dan apabila pengurus keluaran tidak berlari dengan mata lebar, menulis, "Laksanakan isu ini serta-merta dalam keluaran atau perbaikan terbaru."
Tugasan dengan keutamaan biasa atau rendah dibawa dari keluaran ke keluaran. Apabila anda bertanya, "Bilakah tugas ini akan selesai?" anda akan mendapat jawapan seperti, "Maaf, terdapat banyak tugas sekarang. Tanya ketua pasukan atau pengurus keluaran anda."
Masalah dalam pengeluaran lebih diutamakan daripada mencipta ciri baharu. Ulasan buruk akan menyusul jika pengguna sentiasa menghadapi pepijat. Reputasi yang rosak sukar dibaiki.
DevOps menangani isu interaksi antara pembangunan dan sokongan. Akronim ini sering digunakan untuk merujuk kepada orang tertentu yang membantu mencipta persekitaran ujian untuk pembangunan, membina saluran paip CICD dan menggunakan kod yang diuji dengan cepat kepada pengeluaran. DevOps ialah pendekatan kepada pembangunan perisian di mana semua pihak berkepentingan bekerjasama rapat dan membantu mencipta serta mengemas kini produk dan perkhidmatan perisian dengan lebih cepat. Saya merujuk kepada penganalisis, pembangun, penguji dan sokongan.
Dalam pendekatan ini, sokongan dan pembangunan bukanlah jabatan yang berasingan 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 begitu kerap dalam sembang, dan pengguna akhir menjadi lebih gembira.
Sumber: www.habr.com
