Сәлем, Хабр! Мен он жыл бойы Highload IT жүйелеріне қолдау көрсетіп келемін. Бұл мақалада мен 1000+ RPS немесе басқа техникалық мәселелерді шешу үшін Nginx конфигурациялау қиындықтарын қарастырмаймын. Мен осындай жүйелерді қолдау және пайдалану кезінде туындайтын процесс мәселелері туралы өз бақылауларымды бөлісемін.
Бақылау
Техникалық қолдау қызметі билеттің келуін күтпейді: «Сайт не болды?» Қолдау қызметі сайт бұзылған соң бір минут ішінде мәселені көріп, оны түзеуге кірісуі керек. Бірақ веб-сайт айсбергтің шыңыОның қолжетімділігі бақыланатындардың бірі болып табылады.
Интернет-дүкеннің түгендеу ERP жүйесінен түсуін тоқтатқанда не істеу керек? Немесе тұтынушылардың жеңілдіктерін есептейтін CRM жүйесі жауап беруді тоқтатты ма? Дегенмен, веб-сайт жұмыс істеп тұрған сияқты. Мысалы, Zabbix өзінің 200 жауабын алады. Кезекші ауысым бақылаудан ешқандай хабарландыру алмаған және «Тақтар ойыны» жаңа маусымының бірінші эпизодын қуана көріп жатыр.
Көбінесе, бақылау жадтың, жедел жадтың және процессор жүктемесінің күйін өлшеумен шектеледі. серверлер. Бірақ бизнес үшін веб-сайтта өнімнің қолжетімділігін қамтамасыз ету әлдеқайда маңызды. Кластердегі жалғыз виртуалды машинаның істен шығуы трафикті тоқтатуға және басқа серверлердегі жүктемені арттыруға әкеледі. Компания ақша жоғалтпайды.
Сондықтан, серверлердегі операциялық жүйелердің техникалық параметрлерін бақылаумен қатар, бизнес көрсеткіштерін конфигурациялау қажет. Бұл көрсеткіштер сыртқы жүйелермен (CRM, ERP және т.б.) әртүрлі өзара әрекеттесулер, белгілі бір уақыт кезеңіндегі тапсырыстар саны, сәтті немесе сәтсіз тұтынушы рұқсаттары және басқа көрсеткіштер сияқты кіріске тікелей әсер етеді.
Сыртқы жүйелермен әрекеттесу
Жылдық айналымы миллиард рубльден асатын кез келген веб-сайт немесе мобильді қосымша сыртқы жүйелермен өзара әрекеттеседі. Бұл жоғарыда аталған CRM және ERP жүйелерінен сатып алуларды талдау және тұтынушыларға олар міндетті түрде сатып алатын (немесе шын мәнінде сатып алмайтын) өнімдерді ұсыну үшін сату деректерін сыртқы Big Data жүйесіне тасымалдауға дейін. Бұл жүйелердің әрқайсысының өзіндік қолдау жүйесі бар. Және бұл жүйелермен байланысу жиі ауырады, әсіресе мәселе жаһандық болса және көптеген жүйелерде талдауды қажет етеді.
Кейбір жүйелер әкімшілерінің телефон нөмірлерін немесе Telegram тіркелгілерін береді. Басқалары менеджерлерге электрондық пошта жіберуді немесе осы сыртқы жүйелердің қате бақылаушыларына қол жеткізуді талап етеді. Тіпті бір ірі компанияның өзінде әртүрлі жүйелер билетті басқарудың әртүрлі жүйелерінде жиі жұмыс істейді. Билеттің күйін бақылау кейде мүмкін емес. Сіз билетті бір Джирада аласыз. Содан кейін, бірінші Jira-дағы түсініктемеде сіз басқа Jira-дағы тапсырмаға сілтеме қосасыз. Екінші Jira, біреу қазірдің өзінде билетке түсініктеме береді, деп Мәселені шешу үшін гипотетикалық әкімші Андрейге қоңырау шалу керек. Тағыда басқа.
Бұл мәселенің оңтайлы шешімі Slack сияқты біртұтас байланыс кеңістігін құру болады. Оған сыртқы жүйелердің жұмысына қатысатындардың барлығын шақырыңыз. Сондай-ақ, қайталанатын билеттерді болдырмау үшін жалғыз трекер жасаңыз. Билеттер хабарландыруларды бақылаудан бастап өндірістегі қателерді шешуге дейін бір жерде бақылануы керек. Сіз бұл шындыққа жанаспайтын нәрсе және біз бір трекерде жұмыс істейтініміз және олар басқасында жұмыс істейтіні тек тарих мәселесі деп айтуыңыз мүмкін. Әрқайсысының дербес IT командалары бар әртүрлі жүйелер пайда болды. Мен келісемін, сондықтан бұл мәселені жоғарыдан, CIO немесе өнім иесі деңгейінде шешу керек.
Сіз өзара әрекеттесетін әрбір жүйе басымдық берілген мәселені шешу үшін нақты SLA бар қызмет ретінде қолдау көрсетуі керек. Әкімші Андрейдің сәті болған кезде ғана емес.
Кедергі адам
Әрбір жобада (немесе өнімде) демалысы басшылықты ашуландыратын бір адам бар ма? Бұл DevOps инженері, талдаушысы немесе әзірлеушісі болуы мүмкін. Өйткені, қандай серверлерде қандай контейнерлер орнатылғанын, ақаулық туындаған жағдайда контейнерді қалай қайта жүктеу керектігін және іс жүзінде кез келген күрделі мәселені оларсыз шешу мүмкін емес екенін тек DevOps инженері ғана біледі. Сіздің күрделі жүйеңіздің қалай жұмыс істейтінін тек аналитик біледі. Қандай деректер қайда ағып жатыр. Қандай қызметтерге қандай сұраулар қандай параметрлерді талап етеді және қандай жауаптар аламыз.
Кім журналдарда неге қателер бар екенін тез анықтап, өндірістегі маңызды қатені дереу түзете алады? Дәл сол әзірлеуші, әрине. Басқалары бар, бірақ қандай да бір себептермен олар әртүрлі жүйелік модульдердің қалай жұмыс істейтінін түсінеді.
Бұл мәселенің түпкі себебі – құжаттаманың болмауы.Өйткені, егер сіздің жүйеңіздің барлық қызметтері сипатталған болса, сіз мәселені талдаушысыз шеше аласыз. Егер devops барлық серверлерді, қызметтерді және жалпы мәселелерді шешуге арналған нұсқауларды сипаттау үшін бос емес кестеден бірнеше күн кететін болса, мәселені оларсыз шешуге болады. Демалыс кезінде жағажайда сыраны тез бітірудің және мәселені шешу үшін Wi-Fi іздеудің қажеті жоқ.
Көмекші персоналдың құзыреттілігі мен жауапкершілігі
Ірі жобаларда компаниялар әзірлеушілердің жалақысын үнемдемейді. Олар ұқсас жобалардан қымбат орта немесе аға буынды жұмысқа алады. Қолдау мәселесі сәл басқаша. Олар бұл шығындарды барынша азайтуға тырысады. Компаниялар қымбат емес, бұрынғы IT мамандарын жалдап, бетпе-бет келеді. Бұл стратегия, мысалы, Зеленоградтағы зауыттың веб-сайты туралы айтатын болсақ, орындалады.
Егер біз үлкен интернет-дүкен туралы айтатын болсақ, бос уақыттың әрбір сағаты анықтамалық кеңсе әкімшісінің айлық жалақысынан жоғары тұрады. Бастапқы нүкте ретінде жылдық айналымдағы 1 миллиард рубльді алайық. Бұл рейтингтегі кез келген интернет-дүкен үшін ең төменгі айналым. Бұл соманы жылына сағат санына бөліңіз және біз 100 000 рубльден астам таза шығын аламыз. Ал түнгі уақытты алып тастасақ, бұл соманы оңай екі еселей аламыз.
Бірақ ең бастысы ақша емес, солай ма? (Жоқ, әрине, ең бастысы.) Беделді жоғалтулар да бар. Белгілі интернет-дүкеннің құлдырау уақыты әлеуметтік медиа реакцияларының толқынын және салалық бұқаралық ақпарат құралдарындағы жарияланымдарды тудыруы мүмкін. Ас үйдегі достардың арасында «Ол жерден ештеңе сатып алмаңыз, олардың веб-сайты үнемі жұмыс істемейді» деген жолдармен әңгімелесуді есептеу мүмкін емес.
Енді жауапкершілікке. Менде кезекші әкімші веб-сайт жұмыс істемей тұрғаны туралы сайтты бақылау жүйесінің ескертуіне дереу жауап бере алмаған жағдай болды. Жұма күні кешке жағымды жаз болды, Мәскеудің әйгілі интернет-дүкенінің веб-сайты тыныш болды. Сенбі күні таңертең сол веб-сайттың өнім менеджері оның неге жүктелмейтінін түсіне алмады, ал Slack-тегі қолдау және жедел хабарландырулар чаттары үнсіз қалды. Бұл қателік бізге алты санға, ал әкімшінің жұмысына кетті.
Жауапкершілік – дамыту қиын дағды. Біреуде бар немесе жоқ. Сондықтан да мен оны сұхбат барысында адамның жауапкершілікті алуға дағдыланғанын жанама түрде ашатын түрлі сұрақтар арқылы анықтауға тырысамын. Егер біреу колледжді ата-анасы бұйырғандықтан таңдағанын немесе әйелі жалақысы жеткіліксіз деп жұмыс орнын ауыстырып жатқанын айтса, онымен араласпаған дұрыс.
Әзірлеу тобымен өзара әрекеттесу
Пайдаланушылар өндіріс кезінде қарапайым мәселелерге тап болғанда, қолдау оларды дербес шешеді. Олар мәселені қайта шығаруға, журналдарды талдауға және т.б. Бірақ өндірісте қате пайда болған кезде не болады? Бұл жағдайда қолдау әзірлеушілерге тапсырма береді және қызық осыдан басталады.
Әзірлеушілер үнемі шамадан тыс жүктеледі. Олар жаңа мүмкіндіктерді жасаумен айналысады. Өндірістегі қателерді түзету ең қызықты нәрсе емес. Келесі спринтті аяқтаудың соңғы мерзімі жақындап қалды. Содан кейін қолдаудағы жағымсыз адамдар пайда болып, «бәрін дереу тастаңыз, бізде қиындықтар туындады» дейді. Бұл міндеттер ең төменгі басымдық болып табылады. Әсіресе мәселе маңызды емес болса және сайттың негізгі функционалдығы жұмыс істеп тұрса, және шығарылым менеджері бақырайып қарап тұрмаса, «Бұл мәселені келесі шығарылымда немесе түзетуде дереу орындаңыз» деп жазыңыз.
Қалыпты немесе төмен басымдылығы бар тапсырмалар шығарылғаннан шығарылғанға дейін ауыстырылады. «Бұл тапсырма қашан орындалады?» деп сұрағанда. "Кешіріңіз, қазір тапсырмалар көп. Топ жетекшілерінен немесе босату менеджерінен сұраңыз" сияқты жауаптар аласыз.
Өндірістегі мәселелер жаңа мүмкіндіктерді жасаудан басым болады. Пайдаланушылар үнемі қателерге тап болса, жаман шолулар болады. Зақымдалған беделді қалпына келтіру қиын.
DevOps әзірлеу мен қолдау арасындағы өзара әрекеттесу мәселелерін қарастырады. Бұл аббревиатура көбінесе әзірлеуге арналған сынақ орталарын жасауға көмектесетін, CICD құбырларын құрастыратын және сынақтан өткен кодты өндіріске жылдам орналастыратын нақты адамға сілтеме жасау үшін қолданылады. DevOps - бұл барлық мүдделі тараптар тығыз ынтымақтасатын және бағдарламалық өнімдер мен қызметтерді тезірек жасауға және жаңартуға көмектесетін бағдарламалық жасақтаманы әзірлеу тәсілі. Мен аналитиктерді, әзірлеушілерді, тестерлерді және қолдауды айтып отырмын.
Бұл тәсілде қолдау және даму өз мақсаттары мен міндеттері бар бөлек бөлімдер емес. Даму операцияларға қатысады және керісінше. Бөлінген топтардың әйгілі «Мәселе менде емес» деген сөз тіркесі бұдан былай чаттарда жиі кездеспейді және соңғы пайдаланушылар сәл бақытты болады.
Ақпарат көзі: www.habr.com
