Hello, Habr! Sinusuportahan ko ang Highload IT system sa loob ng sampung taon. Hindi ako magsusulat sa artikulong ito tungkol sa mga problema ng pag-set up ng nginx upang gumana sa 1000+ RPS mode o iba pang teknikal na bagay. Ibabahagi ko ang aking mga obserbasyon tungkol sa mga problema sa mga proseso na lumitaw sa suporta at pagpapatakbo ng mga naturang sistema.
Pagsubaybay
Ang teknikal na suporta ay hindi naghihintay hanggang sa dumating ang isang kahilingan na may nilalamang "Ano Bakit... hindi gumagana muli ang site?" Sa loob ng isang minuto pagkatapos mag-crash ang site, dapat na makita ng suporta ang problema at simulan na itong lutasin. Ngunit ang site ay ang dulo ng malaking bato ng yelo. Ang pagkakaroon nito ay isa sa mga unang sinusubaybayan.
Ano ang gagawin sa sitwasyon kapag ang natitirang mga kalakal ng isang online na tindahan ay hindi na dumating mula sa sistema ng ERP? O ang CRM system na nagkalkula ng mga diskwento para sa mga kliyente ay tumigil sa pagtugon? Mukhang gumagana ang site. Natatanggap ng kondisyong Zabbix ang 200 na tugon nito. Ang paglilipat ng tungkulin ay hindi nakatanggap ng anumang mga abiso mula sa pagsubaybay at masayang pinapanood ang unang yugto ng bagong season ng Game of Thrones.
Kadalasang limitado ang pagsubaybay sa pagsukat lamang ng estado ng memorya, RAM at pag-load ng processor ng server. Ngunit para sa negosyo, mas mahalaga na makuha ang availability ng produkto sa website. Ang conditional failure ng isang virtual machine sa cluster ay hahantong sa katotohanan na ang trapiko ay titigil sa pagpunta dito at ang load sa ibang mga server ay tataas. Hindi mawawalan ng pera ang kumpanya.
Samakatuwid, bilang karagdagan sa pagsubaybay sa mga teknikal na parameter ng mga operating system sa mga server, kailangan mong i-configure ang mga sukatan ng negosyo. Mga sukatan na direktang nakakaapekto sa pera. Iba't ibang mga pakikipag-ugnayan sa mga panlabas na sistema (CRM, ERP at iba pa). Ang bilang ng mga order para sa isang tiyak na tagal ng panahon. Matagumpay o hindi matagumpay na mga pahintulot ng kliyente at iba pang mga sukatan.
Pakikipag-ugnayan sa mga panlabas na sistema
Ang anumang website o mobile application na may taunang turnover na higit sa isang bilyong rubles ay nakikipag-ugnayan sa mga panlabas na sistema. Simula sa nabanggit na CRM at ERP at nagtatapos sa paglipat ng data ng mga benta sa isang panlabas na sistema ng Big Data para sa pagsusuri ng mga pagbili at pag-aalok sa kliyente ng isang produkto na tiyak na bibilhin niya (sa katunayan, hindi). Ang bawat ganitong sistema ay may sariling suporta. At kadalasan ang komunikasyon sa mga sistemang ito ay nagdudulot ng sakit. Lalo na kapag ang problema ay pandaigdigan at kailangan mong pag-aralan ito sa iba't ibang mga sistema.
Ang ilang mga system ay nagbibigay ng numero ng telepono o telegrama para sa kanilang mga administrator. Sa isang lugar kailangan mong magsulat ng mga liham sa mga manager o pumunta sa mga bug tracker ng mga panlabas na system na ito. Kahit na sa loob ng konteksto ng isang malaking kumpanya, ang iba't ibang mga sistema ay madalas na nagpapatakbo sa iba't ibang mga sistema ng accounting ng aplikasyon. Minsan nagiging imposibleng subaybayan ang katayuan ng isang aplikasyon. Nakatanggap ka ng kahilingan sa isang kondisyon na Jira. Tapos sa comment nitong unang Jira ay naglagay ka ng link sa isyu sa ibang Jira. Sa pangalawang Jira sa application, may nagsusulat na ng comment niyan kailangan mong tawagan ang may kondisyong admin na si Andrey upang malutas ang isyu. At iba pa.
Ang pinakamahusay na solusyon sa problemang ito ay ang lumikha ng isang solong espasyo para sa komunikasyon, halimbawa sa Slack. Iniimbitahan ang lahat ng kalahok sa proseso ng mga operating external system na sumali. At isa ring tracker para hindi ma-duplicate ang mga application. Dapat na subaybayan ang mga application sa isang lugar, mula sa pagsubaybay sa mga notification hanggang sa output ng mga solusyon sa bug sa hinaharap. Sasabihin mo na ito ay hindi makatotohanan at ito ay nangyari sa kasaysayan na nagtatrabaho kami sa isang tracker, at gumagana sila sa isa pa. Iba't ibang mga sistema ang lumitaw, mayroon silang sariling mga autonomous na IT team. Sumasang-ayon ako, at samakatuwid ang problema ay kailangang malutas mula sa itaas sa antas ng CIO o may-ari ng produkto.
Ang bawat system na iyong nakikipag-ugnayan ay dapat magbigay ng suporta bilang isang serbisyo na may malinaw na SLA upang malutas ang mga isyu ayon sa priyoridad. At hindi kapag may isang minuto ang conditional admin na si Andrey para sa iyo.
Bottleneck Man
Ang lahat ba sa isang proyekto (o produkto) ay may isang tao na ang pagbabakasyon ay nagdudulot ng kombulsyon sa kanilang mga nakatataas? Ito ay maaaring isang devops engineer, analyst o developer. Pagkatapos ng lahat, isang devops engineer lamang ang nakakaalam kung aling mga server ang may kung aling mga lalagyan na naka-install, kung paano i-reboot ang lalagyan kung sakaling magkaroon ng problema, at sa pangkalahatan, ang anumang kumplikadong problema ay hindi malulutas kung wala siya. Ang analyst lang ang nakakaalam kung paano gumagana ang iyong kumplikadong mekanismo. Kung saan pupunta ang mga stream ng data. Sa ilalim ng kung anong mga parameter ng mga kahilingan sa kung aling mga serbisyo, alin ang matatanggap namin ng mga tugon.
Sino ang mabilis na makakaunawa kung bakit may mga error sa mga log at agad na ayusin ang isang kritikal na bug sa produkto? Siyempre ang parehong developer. Mayroong iba, ngunit sa ilang kadahilanan ay siya lamang ang nakakaintindi kung paano gumagana ang iba't ibang mga module ng system.
Ang ugat ng problemang ito ay ang kakulangan ng dokumentasyon. Pagkatapos ng lahat, kung ang lahat ng mga serbisyo ng iyong system ay inilarawan, kung gayon posible na harapin ang problema nang walang isang analyst. Kung ang devops ay tumagal ng ilang araw mula sa kanyang abalang iskedyul at inilarawan ang lahat ng mga server, serbisyo at mga tagubilin para sa paglutas ng mga karaniwang problema, kung gayon ang problema sa kanyang pagkawala ay maaaring malutas nang wala siya. Hindi mo kailangang mabilis na tapusin ang iyong beer sa beach habang nagbabakasyon at maghanap ng wi-fi upang malutas ang problema.
Kakayahan at responsibilidad ng mga tauhan ng suporta
Sa malalaking proyekto, ang mga kumpanya ay hindi nagtitipid sa mga suweldo ng developer. Naghahanap sila ng mga mamahaling middle o senior mula sa mga katulad na proyekto. Sa suporta, ang sitwasyon ay medyo naiiba. Sinusubukan nilang bawasan ang mga gastos na ito sa lahat ng posibleng paraan. Ang mga kumpanya ay kumukuha ng murang mga manggagawa sa Enikey kahapon at matapang na sumabak sa labanan. Posible ang diskarteng ito kung pinag-uusapan natin ang tungkol sa website ng business card ng isang halaman sa Zelenograd.
Kung pinag-uusapan natin ang tungkol sa isang malaking online na tindahan, kung gayon ang bawat oras ng downtime ay nagkakahalaga ng higit sa buwanang suweldo ng isang administrator ng Enikey. Kunin natin ang 1 bilyong rubles ng taunang turnover bilang panimulang punto. Ito ang pinakamababang turnover ng anumang online na tindahan mula sa rating . Hatiin ang halagang ito sa bilang ng mga oras bawat taon at makakuha ng higit sa 100 rubles ng mga netong pagkalugi. At kung hindi mo bibilangin ang mga oras ng gabi, ligtas mong madodoble ang halaga.
Ngunit hindi pera ang pangunahing bagay, tama? (hindi, siyempre ang pangunahing bagay) Mayroon ding pagkalugi sa reputasyon. Ang pagbagsak ng isang kilalang online na tindahan ay maaaring magdulot ng parehong wave ng mga review sa mga social network at mga publikasyon sa thematic media. At ang mga pag-uusap ng mga kaibigan sa kusina sa estilo ng "Huwag bumili ng kahit ano doon, ang kanilang website ay palaging down" ay hindi masusukat sa lahat.
Ngayon sa responsibilidad. Sa aking pagsasanay, mayroong isang kaso kapag ang administrator na naka-duty ay hindi tumugon sa oras sa isang abiso mula sa sistema ng pagsubaybay tungkol sa hindi magagamit ng site. Sa isang kaaya-ayang tag-araw Biyernes ng gabi, ang website ng isang kilalang online na tindahan sa Moscow ay tahimik na nakahiga. Noong Sabado ng umaga, hindi naunawaan ng tagapamahala ng produkto ng site na ito kung bakit hindi nagbukas ang site, at nagkaroon ng katahimikan sa suporta at kagyat na mga pakikipag-chat sa notification sa Slack. Ang nasabing pagkakamali ay nagkakahalaga sa amin ng anim na numero, at ang tungkulin ng opisyal na ito ay kanyang trabaho.
Ang responsibilidad ay isang mahirap na kasanayang paunlarin. Alinman sa isang tao ay mayroon nito o wala. Samakatuwid, sa panahon ng mga panayam, sinusubukan kong tukuyin ang presensya nito sa iba't ibang mga katanungan na hindi direktang nagpapakita kung ang isang tao ay nakasanayan na kumuha ng responsibilidad. Kung ang isang tao ay sumagot na siya ay pumili ng isang unibersidad dahil ang kanyang mga magulang ay nagsabi o nagpalit ng trabaho dahil ang kanyang asawa ay nagsabi na siya ay hindi sapat ang kanyang kinikita, kung gayon mas mahusay na huwag makisali sa mga ganitong tao.
Pakikipag-ugnayan sa pangkat ng pagbuo
Kapag ang mga gumagamit ay nakatagpo ng mga simpleng problema sa isang produkto sa panahon ng operasyon, ang suporta ay malulutas ang mga ito sa kanilang sarili. Sinusubukang kopyahin ang problema, sinusuri ang mga log, at iba pa. Ngunit ano ang gagawin kapag lumitaw ang isang bug sa produkto? Sa kasong ito, itinatalaga ng suporta ang gawain sa mga developer at dito magsisimula ang kasiyahan.
Ang mga developer ay palaging overload. Gumagawa sila ng mga bagong feature. Ang pag-aayos ng mga bug sa mga benta ay hindi ang pinakakawili-wiling aktibidad. Malapit na ang mga takdang panahon upang makumpleto ang susunod na sprint. At pagkatapos ay dumating ang mga hindi kasiya-siyang tao mula sa suporta at sasabihin: "Ihinto kaagad ang lahat, mayroon kaming mga problema." Ang priyoridad ng naturang mga gawain ay minimal. Lalo na kapag ang problema ay hindi ang pinaka-kritikal at ang pangunahing pag-andar ng site ay gumagana, at kapag ang tagapamahala ng release ay hindi tumatakbo sa paligid na may nakaumbok na mga mata at sumulat ng: "Agad na idagdag ang gawaing ito sa susunod na release o hotfix."
Ang mga isyung may normal o mababang priyoridad ay inililipat mula sa release patungo sa release. Sa tanong na "Kailan matatapos ang gawain?" makakatanggap ka ng mga sagot sa istilong: βPaumanhin, maraming gawain ngayon, tanungin ang iyong mga lead team o release manager.β
Mas mataas ang priyoridad ng mga problema sa pagiging produktibo kaysa sa paggawa ng mga bagong feature. Hindi magtatagal ang masasamang pagsusuri kung ang mga gumagamit ay patuloy na natitisod sa mga bug. Mahirap ibalik ang nasirang reputasyon.
Ang mga isyu sa pakikipag-ugnayan sa pagitan ng pag-unlad at suporta ay nireresolba ng DevOps. Ang pagdadaglat na ito ay kadalasang ginagamit sa anyo ng isang partikular na tao na tumutulong sa paglikha ng mga kapaligiran sa pagsubok para sa pag-unlad, bubuo ng mga pipeline ng CICD at mabilis na nagdadala ng sinubok na code sa produksyon. Ang DevOps ay isang diskarte sa pagbuo ng software kapag ang lahat ng kalahok sa proseso ay malapit na nakikipag-ugnayan sa isa't isa at tumulong upang mabilis na gumawa at mag-update ng mga produkto at serbisyo ng software. Ang ibig kong sabihin ay mga analyst, developer, tester at suporta.
Sa ganitong paraan, ang suporta at pag-unlad ay hindi magkakaibang mga departamento na may sariling mga layunin at layunin. Ang pag-unlad ay kasangkot sa operasyon at vice versa. Ang sikat na parirala ng mga ipinamahagi na koponan: "Ang problema ay wala sa aking panig" ay hindi na madalas na lumilitaw sa mga chat, at ang mga end user ay nagiging mas masaya.
Pinagmulan: www.habr.com