{"id":32958,"date":"2019-10-31T21:49:56","date_gmt":"2019-10-31T18:49:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/pyat-problem-v-protsessah-ekspluatatsii-i-podderzhki-highload-it-sistem\/"},"modified":"2019-10-31T21:49:56","modified_gmt":"2019-10-31T18:49:56","slug":"pyat-problem-v-protsessah-ekspluatatsii-i-podderzhki-highload-it-sistem","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/pyat-problem-v-protsessah-ekspluatatsii-i-podderzhki-highload-it-sistem","title":{"rendered":"Fem problemer i drifts- og supportprocesser for Highload IT-systemer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, Habr! I ti \u00e5r har jeg st\u00f8ttet Highload IT-systemer. Jeg vil ikke skrive om problemerne med at konfigurere nginx til at arbejde i en tilstand med 1000+ RPS eller andre tekniske emner i denne artikel. Jeg vil dele nogle observationer om de problemer, der opst\u00e5r i processerne, der kr\u00e6ves for at underst\u00f8tte og drifte s\u00e5danne systemer. <\/a><\/noindex><\/p>\n

Overv\u00e5gning<\/h2>\n

\nSupporten venter ikke, indtil der kommer en foresp\u00f8rgsel med indholdet 'Hvad sker der?\u2026 hjemmesiden virker ikke igen?'. Supporten skal hurtigt efter, at hjemmesiden er faldet, se problemet og begynde at l\u00f8se det. Men hjemmesiden er kun toppen af isbjerget.<\/b>Dens tilg\u00e6ngelighed overv\u00e5ges som en af de f\u00f8rste.<\/p>\n

Hvad skal man g\u00f8re i en situation, hvor lagrene i en online butik stopper med at komme fra ERP-systemet? Eller CRM-systemet, der beregner rabatter for kunderne, stopper med at svare? Hjemmesiden ser ud til at fungere. Den virtuelle overv\u00e5gning f\u00e5r sit 200 svar. Det vagthold, der er p\u00e5 arbejde, modtager ingen underretninger fra overv\u00e5gningen og ser glad den f\u00f8rste episode af den nye s\u00e6son af 'Game of Thrones'.<\/p>\n

Ofte er overv\u00e5gningen kun begr\u00e6nset til at m\u00e5le tilstanden af hukommelse, RAM og belastningen p\u00e5 processorerne. servere<\/a>.<\/b> Men for erhvervslivet er det meget vigtigere at f\u00e5 information om tilg\u00e6ngeligheden af varer p\u00e5 hjemmesiden. Et hypotetisk fald af en virtuel maskine i klyngen vil f\u00f8re til, at trafikken stopper med at g\u00e5 til den, og belastningen p\u00e5 de andre servere vil stige. Virksomheden vil ikke miste penge.<\/p>\n

Derfor skal man udover overv\u00e5gning af tekniske parametre i operativsystemerne p\u00e5 serverne ogs\u00e5 indf\u00f8re forretningsmetrikker. Metrikker, der direkte p\u00e5virker pengene. Forskellige interaktioner med eksterne systemer (CRM, ERP osv.). Antallet af ordrer i en bestemt tidsperiode. Succesfulde eller mislykkedes kunderettigheder og andre metrikker.<\/p>\n

Interaktion med eksterne systemer<\/h2>\n

\nEnhver hjemmeside eller mobilapplikation med en \u00e5rlig oms\u00e6tning p\u00e5 over en milliard rubler interagerer med eksterne systemer. Fra de f\u00f8rn\u00e6vnte CRM- og ERP-systemer til overf\u00f8rslen af data om salg til et eksternt Big Data-analyse system, der analyserer k\u00f8b og foresl\u00e5r varer til kunden, som de helt sikkert vil k\u00f8be (det g\u00f8r de faktisk ikke). Hver s\u00e5dan system har sin egen support. Og ofte medf\u00f8rer kommunikation med disse systemer smerter. Is\u00e6r n\u00e5r problemet er globalt og skal analyseres p\u00e5 tv\u00e6rs af forskellige systemer.<\/p>\n

Nogle systemer giver telefonnummer eller telegram til deres administratorer. Andre steder skal man skrive e-mails til managerne eller g\u00e5 ind i bug trackere for disse eksterne systemer. Selv inden for en stor virksomhed arbejder forskellige systemer ofte i forskellige ticketing systemer. At f\u00f8lge status for en ticket kan nogle gange v\u00e6re umuligt. Du modtager en ticket i \u00e9n hypotetisk Jira. Derefter s\u00e6tter du et link til opgaven i en anden Jira i kommentaren til denne f\u00f8rste Jira. I den anden Jira skriver nogen allerede en kommentar om, at man skal ringe til den hypotetiske administrator Andrey for at l\u00f8se problemet.<\/b> Og s\u00e5 videre.<\/p>\n

Den optimale l\u00f8sning p\u00e5 et s\u00e5dant problem ville v\u00e6re at skabe et f\u00e6lles rum for kommunikation, for eksempel i Slack. At invitere alle deltagere i driftsprocessen af de eksterne systemer. Og ogs\u00e5 et f\u00e6lles tracker for ikke at duplikere tickets. Tickets b\u00f8r f\u00f8lges i \u00e9t sted, fra overv\u00e5gningsmeddelelser til l\u00f8sning af bugs i produktion. Du vil m\u00e5ske sige, at dette er urealistisk, og I har historisk set arbejdet i \u00e9n tracker, mens de arbejder i en anden. Der opstod forskellige systemer, og de havde deres egne autonome IT-teams. Jeg er enig, og derfor skal problemet l\u00f8ses fra top til bund, p\u00e5 niveau med CIO eller produkt ejer.<\/p>\n

Hver system, som du interagerer med, b\u00f8r yde support som en tjeneste med en klar SLA for l\u00f8sning af problemer efter prioriteter. Og ikke kun n\u00e5r den hypotetiske administrator Andrey har et minut til dig.<\/p>\n

Mennesket \u2013 flaskehalsen<\/h2>\n

\nEr der en person p\u00e5 projektet (eller produktet), hvis ferie f\u00e5r cheferne til at f\u00e5 anfald? Dette kan v\u00e6re en devops ingeni\u00f8r, analytiker eller udvikler. For kun devops ingeni\u00f8ren ved, hvilke servere der har hvilke containere installeret, hvordan man genstarter en container i tilf\u00e6lde af problemer, og enhver kompleks problem uden ham l\u00f8ses ikke. Analytikeren er den eneste, der ved, hvordan dit komplekse system fungerer. Hvilke datastreams der g\u00e5r hvor. Under hvilke parametre der foretages anmodninger til hvilke tjenester, og hvilke svar vi vil modtage.
\nHvem forst\u00e5r hurtigt, hvorfor der er fejl i loggene og hurtigt kan fikse en kritisk bug i produktionen? Selvf\u00f8lgelig, det samme udvikler. Der er andre, men af en eller anden grund er det kun ham, der forst\u00e5r, hvordan forskellige moduler i systemet fungerer.<\/p>\n

Kernen i dette problem er manglen p\u00e5 dokumentation.<\/b>For hvis alle tjenester i dit system var beskrevet, kunne man l\u00f8se problemet uden en analytiker. Hvis devops havde taget et par dage ud af sin t\u00e6tte tidsplan og beskrevet alle servere, tjenester og instruktioner til l\u00f8sning af typiske problemer, kunne vi ogs\u00e5 have l\u00f8st problemet i hans frav\u00e6r. Man beh\u00f8ver ikke at drikke sit \u00f8l hurtigt p\u00e5 stranden i ferien og lede efter wi-fi for at l\u00f8se et problem.<\/p>\n

Kompetence og ansvar for supportmedarbejdere<\/h2>\n

\nI store projekter spare virksomheder ikke p\u00e5 l\u00f8nninger til udviklerne. De jagter dyre mid-levels eller seniors fra lignende projekter. Situationen er lidt anderledes med support. Disse omkostninger fors\u00f8ges at blive reduceret. Virksomheder ans\u00e6tter billige nyuddannede IT-supportere og g\u00e5r modigt ind i kampen. En s\u00e5dan strategi er mulig, hvis vi taler om et visitkort-website for en fabrik i Zelenograd.<\/p>\n

Hvis vi taler om en stor online butik, koster hver time med nedetid mere end en m\u00e5nedsl\u00f8n for en IT-supporter. Lad os tage udgangspunkt i 1 milliard rubler i \u00e5rlig oms\u00e6tning. Dette er den minimale oms\u00e6tning for enhver online butik fra ranglisten TOP-100 for 2018<\/a><\/noindex>. Vi deler dette bel\u00f8b med antallet af timer p\u00e5 et \u00e5r og f\u00e5r over 100.000 rubler i netto tab. Og hvis vi ikke t\u00e6ller nat timerne med, kan vi trygt fordoble bel\u00f8bet.<\/p>\n

Men penge er jo ikke det vigtigste, ikke?<\/b> (nej, selvf\u00f8lgelig er det vigtigt) Der er ogs\u00e5 omd\u00f8mmetab. En time med nedbrud for en kendt online butik kan f\u00f8re til b\u00e5de b\u00f8lger af anmeldelser p\u00e5 sociale medier og publikationer i specialiserede medier. Og samtaler mellem venner i k\u00f8kkenet som 'K\u00f8b ikke noget der, deres website virker konstant ikke' kan slet ikke m\u00e5les.<\/p>\n

Nu til ansvaret. I min erfaring har der v\u00e6ret tilf\u00e6lde, hvor den vagthavende administrator ikke reagerede rettidigt p\u00e5 meddelelser fra overv\u00e5gningssystemet om, at hjemmesiden var utilg\u00e6ngelig. P\u00e5 en dejlig sommerfredag aften l\u00e5 et velkendt online butikswebsite stille. Om l\u00f8rdagen morgen forstod produktlederen ikke, hvorfor hjemmesiden ikke kunne \u00e5bnes, og der var stille i supportchattene og de hastige meddelelser i Slack. Denne fejl kostede os en sekscifret sum, og denne vagt mistede sit job.<\/p>\n

Ansvar er en f\u00e6rdighed, der er sv\u00e6r at udvikle. <\/b>Enten har en person det, eller s\u00e5 har de det ikke. Derfor pr\u00f8ver jeg ved jobsamtaler at afd\u00e6kke dets tilstedev\u00e6relse med forskellige sp\u00f8rgsm\u00e5l, som indirekte viser, om personen er vant til at p\u00e5tage sig ansvar. Hvis en person svarer, at de valgte universitetet, fordi for\u00e6ldrene sagde det, eller skifter job, fordi konen sagde, at de tjener for lidt, s\u00e5 er det bedst ikke at samarbejde med s\u00e5danne mennesker.<\/p>\n

Interaktion med udviklingsteamet<\/h2>\n

\nN\u00e5r der opst\u00e5r enkle problemer for brugerne i produktionen, l\u00f8ser supporten dem selv. De pr\u00f8ver at genskabe problemet, analyserer logfiler osv. Men hvad skal man g\u00f8re, n\u00e5r der dukker en fejl op i produktionen? I s\u00e5 fald opretter supporten en opgave til udviklerne, og det er her, det bliver virkelig interessant.<\/p>\n

Udviklerne er konstant overbelastede.<\/b> De arbejder p\u00e5 at skabe nye funktioner. At fikse fejl i produktionen er ikke ligefrem den mest sp\u00e6ndende opgave. Fristerne for at afslutte den n\u00e6ste sprint n\u00e6rmer sig. Og s\u00e5 kommer ubehagelige mennesker fra supporten og siger: \"Skal vi straks droppe alt, vi har problemer\". Prioriteten for s\u00e5danne opgaver er minimal. Is\u00e6r n\u00e5r problemet ikke er kritisk, og den grundl\u00e6ggende funktionalitet p\u00e5 hjemmesiden fungerer, og n\u00e5r udgivelseslederen ikke l\u00f8ber rundt med store \u00f8jne og skriver: \"Skal denne opgave straks tilf\u00f8jes til den n\u00e6rmeste udgivelse eller hotfix\".<\/p>\n

Opgaver med almindelig eller lav prioritet flytter fra udgivelse til udgivelse. N\u00e5r man sp\u00f8rger: \"Hvorn\u00e5r bliver opgaven udf\u00f8rt?\" vil man f\u00e5 svar i stil med: \"Beklager, der er mange opgaver lige nu, sp\u00f8rg teamlederne eller udgivelseslederen\".<\/p>\n

Problemer i produktionen har h\u00f8jere prioritet end at skabe nye funktioner. D\u00e5rlige anmeldelser lader ikke vente p\u00e5 sig, hvis brugerne konstant st\u00f8der p\u00e5 fejl. Det er sv\u00e6rt at genoprette et \u00f8delagt omd\u00f8mme.<\/p>\n

Sp\u00f8rgsm\u00e5l om interaktionen mellem udvikling og support l\u00f8ses af DevOps.<\/b> Denne forkortelse bruges ofte til at betegne en konkret person, der hj\u00e6lper med at oprette testmilj\u00f8er til udvikling, bygger CICD-pipelines og hurtigt bringer testet kode til produktion. DevOps er en tilgang til softwareudvikling, hvor alle deltagere i processen arbejder t\u00e6t sammen og hj\u00e6lper med at skabe og opdatere softwareprodukter og tjenester hurtigere. Jeg mener analytikere, udviklere, testere og support.<\/p>\n

Support and development in this approach are not separate departments with their own goals and tasks. Development is involved in operations and vice versa. The famous phrase from distributed teams, \"The problem is not on my side,\" is not so frequently seen in chats anymore, and end users are becoming a little happier.
\n
Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0414\u0435\u0441\u044f\u0442\u044c \u043b\u0435\u0442 \u044f \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u044e Highload \u0418\u0422 \u0441\u0438\u0441\u0442\u0435\u043c\u044b. \u041d\u0435 \u0431\u0443\u0434\u0443 \u043f\u0438\u0441\u0430\u0442\u044c \u0432 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043e \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0445 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 nginx \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u0440\u0435\u0436\u0438\u043c\u0435 1000+ RPS \u0438\u043b\u0438 \u0434\u0440\u0443\u0433\u0438\u0435 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u0432\u0435\u0449\u0438. \u041f\u043e\u0434\u0435\u043b\u044e\u0441\u044c \u043d\u0430\u0431\u043b\u044e\u0434\u0435\u043d\u0438\u044f\u043c\u0438 \u043e \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0445 \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u044e\u0442 \u0432 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u0438 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u0442\u0430\u043a\u0438\u0445 \u0441\u0438\u0441\u0442\u0435\u043c. \u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u0422\u0435\u0445\u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0430 \u043d\u0435 \u0436\u0434\u0435\u0442 \u043f\u043e\u043a\u0430 \u043f\u0440\u0438\u043b\u0435\u0442\u0438\u0442 \u0437\u0430\u044f\u0432\u043a\u0430 \u0441 \u0441\u043e\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435\u043c \u00ab \u041a\u0430\u043a\u043e\u0433\u043e \u041f\u043e\u0447\u0435\u043c\u0443\u2026 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32958","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Five problems in the processes of operating and supporting high-load IT systems | ProHoster","description":"Hello, Habr! For ten years, I have been supporting high-load IT systems. I won\u2019t write in this article about the challenges of configuring nginx to work in 1000+ RPS mode or other technical matters.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/pyat-problem-v-protsessah-ekspluatatsii-i-podderzhki-highload-it-sistem","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u044f\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u0445 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0438 Highload \u0418\u0422 \u0441\u0438\u0441\u0442\u0435\u043c | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0414\u0435\u0441\u044f\u0442\u044c \u043b\u0435\u0442 \u044f \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u044e Highload \u0418\u0422 \u0441\u0438\u0441\u0442\u0435\u043c\u044b. \u041d\u0435 \u0431\u0443\u0434\u0443 \u043f\u0438\u0441\u0430\u0442\u044c \u0432 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043e \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u0445 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 nginx \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u0440\u0435\u0436\u0438\u043c\u0435 1000+ RPS \u0438\u043b\u0438 \u0434\u0440\u0443\u0433\u0438\u0435 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u0432\u0435\u0449\u0438.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/pyat-problem-v-protsessah-ekspluatatsii-i-podderzhki-highload-it-sistem","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:49:56+00:00","article:modified_time":"2019-10-31T18:49:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32958","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 17:02:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:49:37","updated":"2026-02-09 17:02:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/32958","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=32958"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/32958\/revisions"}],"predecessor-version":[{"id":158569,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/32958\/revisions\/158569"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=32958"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=32958"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=32958"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}