Sugeng rawuh, Habr! Aku wis ndhukung sistem IT Highload sepuluh taun. Aku ora bakal nulis ing artikel iki babagan masalah nyetel nginx supaya bisa digunakake ing mode 1000+ RPS utawa bab teknis liyane. Aku bakal nuduhake pengamatan babagan masalah ing proses sing muncul ing dhukungan lan operasi sistem kasebut.
Ngawasi
Dhukungan teknis ora ngenteni nganti panjaluk teka kanthi konten "Apa Kenapa ... situs ora bisa digunakake maneh?" Ing sawetara menit sawise situs tubrukan, support kudu wis ndeleng masalah lan miwiti kanggo ngatasi iku. Nanging situs kasebut minangka pucuk gunung es. Kasedhiyan kasebut minangka salah sawijining sing pertama dipantau.
Apa sing kudu ditindakake nalika barang sing isih ana ing toko online ora ana maneh saka sistem ERP? Utawa sistem CRM sing ngetung diskon kanggo klien mandheg nanggapi? Situs kasebut katon bisa digunakake. Zabbix kondisional nampa 200 respon. Pergeseran tugas durung nampa kabar saka pemantauan lan seneng nonton episode pertama musim anyar Game of Thrones.
Ngawasi asring diwatesi mung kanggo ngukur status memori, RAM lan beban prosesor server. Nanging kanggo bisnis luwih penting kanggo entuk kasedhiyan produk ing situs web. Gagal kondisional siji mesin virtual ing kluster bakal nyebabake kasunyatan manawa lalu lintas bakal mandheg lan beban ing server liyane bakal nambah. Perusahaan ora bakal kelangan dhuwit.
Mulane, saliyane ngawasi paramèter teknis sistem operasi ing server, sampeyan kudu ngatur metrik bisnis. Metrik sing langsung mengaruhi dhuwit. Macem-macem interaksi karo sistem eksternal (CRM, ERP lan liya-liyane). Jumlah pesenan kanggo wektu tartamtu. Otorisasi klien sing sukses utawa ora sukses lan metrik liyane.
Interaksi karo sistem njaba
Sembarang situs web utawa aplikasi seluler kanthi omset taunan luwih saka milyar rubel sesambungan karo sistem eksternal. Miwiti saka CRM lan ERP sing kasebut ing ndhuwur lan diakhiri karo transfer data dodolan menyang sistem Big Data eksternal kanggo nganalisa tumbas lan nawakake klien produk sing mesthi bakal dituku (nyatane, ora). Saben sistem kasebut duwe dhukungan dhewe. Lan asring komunikasi karo sistem kasebut nyebabake rasa nyeri. Utamane yen masalah kasebut global lan sampeyan kudu nganalisa ing macem-macem sistem.
Sawetara sistem nyedhiyakake nomer telpon utawa telegram kanggo panguruse. Nang endi wae sampeyan kudu nulis layang menyang manajer utawa menyang pelacak bug saka sistem eksternal kasebut. Malah ing konteks siji perusahaan gedhe, sistem sing beda asring digunakake ing sistem akuntansi aplikasi sing beda. Kadhangkala dadi mokal kanggo nglacak status aplikasi. Sampeyan nampa panjalukan ing siji Jira kondisional. Banjur ing komentar saka Jira pisanan iki sampeyan sijine link kanggo masalah ing Jira liyane. Ing Jira kapindho ing aplikasi, ana sing wis nulis komentar sing sampeyan kudu nelpon admin saratipun Andrey kanggo mutusake masalah masalah. Lan liyane.
Solusi sing paling apik kanggo masalah iki yaiku nggawe papan siji kanggo komunikasi, contone ing Slack. Ngundang kabeh peserta ing proses operasi sistem njaba kanggo gabung. Lan uga tracker siji supaya ora duplikat aplikasi. Aplikasi kudu dilacak ing sak panggonan, saka ngawasi kabar nganti metu saka solusi bug ing mangsa ngarep. Sampeyan bakal ujar manawa iki ora realistis lan ana sejarah yen kita kerja ing siji tracker, lan padha kerja ing liyane. Sistem sing beda-beda muncul, dheweke duwe tim IT otonom dhewe. Aku setuju, lan mulane masalah kasebut kudu ditanggulangi saka ndhuwur ing tingkat CIO utawa pemilik produk.
Saben sistem sing sampeyan sesambungan kudu menehi dhukungan minangka layanan kanthi SLA sing jelas kanggo ngatasi masalah kanthi prioritas. Lan ora nalika admin kondisional Andrey duwe menit kanggo sampeyan.
Wong Bottleneck
Apa saben wong ing proyek (utawa produk) duwe wong sing arep liburan nyebabake kejang ing antarane atasan? Iki bisa dadi insinyur devops, analis utawa pangembang. Sawise kabeh, mung insinyur devops sing ngerti server endi sing wis diinstal kontaner, carane urip maneh wadhah kasebut yen ana masalah, lan umume, masalah rumit ora bisa ditanggulangi tanpa dheweke. Analis mung siji sing ngerti cara kerja mekanisme kompleks sampeyan. Sing data stream menyang ngendi. Ing paramèter apa panjalukan kanggo layanan apa, sing bakal nampa respon.
Sapa sing bakal ngerti kanthi cepet kenapa ana kesalahan ing log lan kanthi cepet ndandani bug kritis ing produk kasebut? Mesthi pangembang sing padha. Ana liyane, nanging sakperangan alesan mung mangerténi carane modul beda saka sistem.
Oyod saka masalah iki yaiku kekurangan dokumentasi. Sawise kabeh, yen kabeh layanan sistem sampeyan diterangake, mula masalah kasebut bisa ditindakake tanpa analis. Yen devops njupuk sawetara dina metu saka jadwal sibuk lan njlèntrèhaké kabeh server, layanan lan instruksi kanggo ngatasi masalah khas, banjur masalah ing anané bisa ditanggulangi tanpa wong. Sampeyan ora perlu cepet rampung bir ing pantai nalika preian lan goleki wi-fi kanggo ngatasi masalah.
Kompetensi lan tanggung jawab staf dhukungan
Ing proyek gedhe, perusahaan ora ngetung gaji pangembang. Dheweke nggoleki wong tengah utawa senior sing larang saka proyek sing padha. Kanthi dhukungan, kahanan kasebut rada beda. Dheweke nyoba nyuda biaya kasebut kanthi cara apa wae. Perusahaan nyewa buruh Enikey wingi sing murah lan kanthi kendel melu perang. Strategi iki bisa ditindakake yen kita ngomong babagan situs web kertu bisnis tanduran ing Zelenograd.
Yen kita ngomong babagan toko online sing gedhe, mula saben jam downtime luwih akeh tinimbang gaji saben wulan administrator Enikey. Ayo njupuk 1 milyar rubel omset taunan minangka titik wiwitan. Iki minangka turnover minimal saka toko online saka rating . Dibagi jumlah iki kanthi jumlah jam saben taun lan entuk luwih saka 100 rubel kerugian net. Lan yen sampeyan ora ngetung jam wengi, sampeyan bisa kanthi aman pindho jumlah.
Nanging dhuwit dudu perkara utama, ta? (ora, mesthi bab utama) Ana uga losses reputasi. Kejatuhan toko online sing kondhang bisa nyebabake gelombang review ing jaringan sosial lan publikasi ing media tematik. Lan obrolan kanca-kanca ing pawon kanthi gaya "Aja tuku apa-apa ana, situs web tansah mudhun" ora bisa diukur.
Saiki tanggung jawab. Ing praktikku, ana kasus nalika administrator sing tugas ora nanggapi ing wektu kanggo kabar saka sistem pemantauan babagan ora kasedhiya situs kasebut. Ing wayah sore ana mangsa panas sing nyenengake, situs web toko online sing kondhang ing Moskow kanthi tenang. Setu esuk, manajer produk situs iki ora ngerti kenapa situs kasebut ora mbukak, lan ana bisu ing dhukungan lan obrolan kabar sing penting ing Slack. Kesalahan kuwi biaya kita jumlah enem tokoh, lan iki pejabat tugas proyek.
Tanggung jawab minangka skill sing angel dikembangake. Salah siji wong duwe utawa ora. Mula, sajrone wawancara, aku nyoba ngenali anane kanthi macem-macem pitakonan sing ora langsung nuduhake manawa wong wis biasa tanggung jawab. Nèk ana wong sing njawab nèk dhèwèké milih universitas merga wong tuwané kandha ngono utawa pindah kerja merga bojoné kandha nèk penghasilané ora cukup, mula luwih becik ora mèlu-mèlu karo wong-wong kuwi.
Interaksi karo tim pangembangan
Nalika pangguna nemoni masalah sing gampang karo produk sajrone operasi, dhukungan bisa ngrampungake dhewe. Nyoba kanggo ngasilake masalah, nganalisa log, lan liya-liyane. Nanging apa sing kudu ditindakake nalika ana bug ing produk kasebut? Ing kasus iki, dhukungan menehi tugas kanggo pangembang lan ing kene kesenengan kasebut diwiwiti.
Pangembang tansah overloaded. Dheweke nggawe fitur anyar. Ndandani kewan omo karo dodolan dudu kegiatan sing paling menarik. Tenggat wektu wis cedhak kanggo ngrampungake sprint sabanjure. Banjur wong sing ora seneng saka dhukungan teka lan ujar: "Enggal-enggal, kita duwe masalah." Prioritas tugas kasebut minimal. Utamane yen masalah kasebut dudu sing paling kritis lan fungsi utama situs kasebut bisa digunakake, lan nalika manajer rilis ora mlaku-mlaku kanthi mripat bulging lan nulis: "Cepat tambahake tugas iki menyang rilis utawa hotfix sabanjure."
Masalah karo prioritas normal utawa kurang dipindhah saka release kanggo release. Kanggo pitakonan "Kapan tugas bakal rampung?" sampeyan bakal nampa jawaban kanthi gaya: "Ngapunten, saiki akeh tugas, takon pimpinan tim utawa manajer rilis."
Masalah produktivitas njupuk prioritas sing luwih dhuwur tinimbang nggawe fitur anyar. Tinjauan ala ora bakal suwe yen pangguna terus-terusan kesandhung kewan omo. Reputasi sing rusak angel dipulihake.
Masalah interaksi antarane pembangunan lan dhukungan ditanggulangi dening DevOps. Singkatan iki asring digunakake ing wangun wong tartamtu sing mbantu nggawe lingkungan test kanggo pembangunan, mbangun pipelines CICD lan cepet nggawa kode dites menyang produksi. DevOps minangka pendekatan kanggo pangembangan piranti lunak nalika kabeh peserta ing proses kasebut rapet sesambungan lan mbantu nggawe lan nganyari produk lan layanan piranti lunak kanthi cepet. Maksudku analis, pangembang, penguji lan dhukungan.
Ing pendekatan iki, dhukungan lan pangembangan ora beda departemen kanthi tujuan lan tujuane dhewe. Pangembangan melu operasi lan kosok balene. Frasa misuwur saka tim sing disebarake: "Masalah ora ana ing sisihku" ora katon maneh ing obrolan, lan pangguna pungkasan dadi luwih seneng.
Source: www.habr.com