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