Платформалар шетіндегі проблема неде

Өнімділік мәселелері әдетте бір жерде ғана болмайды. Қолданушыға бәрі қарапайым көрінеді: жүйе баяу ашылады, есептер қалыптыдан ұзақ құрылады, таңертең бәрі тежеледі. Бірақ бір ғана шағымның артында бірнеше себеп тұруы мүмкін: серверге ресурс жетпейді, виртуалдық орта жүктемені қайта бөлді, ал СУБД сол сәтте дискке немесе жадқа күтіп отыр.

Сондықтан да командалар арасында даулар жиі шығады. Бірі жабдықтың бәрі дұрыс деп айтады. Басқасы виртуализация хостында қателер көрмейді. DBA көрсетеді, сұраныстар ауырлады немесе базаға IOPS жетпейді. Жеке-жеке әр тарап дұрыс болуы мүмкін, бірақ толық картина әлі болмауы мүмкін.

Содан себеп іздеу жиі кінә іздеуге айналады. Әр команда тек өз графиктерін мен логтарын қарап тұрғанда әңгіме шеңберінде қайталана береді. Бизнес үшін нақты тар шекарада қай жерде шектеу екенін білудің өзі маңызды емес — ол үшін маңыздысы: сервис баяу, шешім қабылдау мерзімі ұзауда.

Көбіне мұндай дау үш себеппен созылады: командаларда қолданылатын метрикалар әртүрлі, тексеру тәртібі алдын ала келісілмеген және қабылданатын жылдамдықтың жалпы нормасы жоқ. Осы келісімдер болмаса, бүгін сақтау жүйесін күдіктенеді, ертең гипервизорды, кейін база баптамаларын. Әр жаңа тексеру уақытты алады, ал жүйе сол кезде жүктемеде қала береді.

Бұл әсіресе серверлер, виртуализация, СУБД және қолданбалы ПО әр түрлі мердігерлермен жүргізілетін жерлерде жиі кездеседі. Сондықтан жоба басталғанға дейін «интегратор жауапты» деген жалпылықпен емес, қадамдап: деградация фактісін кім растайды, деректерді кім жинайды, әрі қарайғы тексеріс туралы шешімді кім қабылдайтынын келісу маңызды.

Бұл үлкен мемлекеттік, банк, білім және медицина салаларындағы ірі енгізулер үшін аса маңызды. Мұндай жобаларда инфрақұрылым бірнеше қабаттан тұрады, ал тоқтап қалулар қымбатқа түседі. Ережелерді алдын ала белгілемесеңіз, тіпті мықты командалар да себепті жоюдан гөрі ұзақша таласады.

Қандай рөлдер бастапқы күннен қажет

Жоба серверлер, виртуализация және СУБД болса, өнімділікке жауапкершілікті кейінге қалдыру болмайды. Әйтпесе алғашқы төмендеу кезінде әр команда тек өз аумағын көреді, ал бизнестің орнына шешудің орнына ұзақ дау түседі.

Рөлдерді компания атаулары бойынша емес, функциялар бойынша атай берген жөн. Тіпті инфрақұрылымның бір бөлігін бір мердігер, ал программалық бөлігін басқа жүргізсе де, жауапкершілік аймағы ашық болуы керек.

Кем дегенде бес рөл қажет:

серверлер мен ресурстар иесі — физикалық инфрақұрылым деңгейіндегі процессорлар, жад, дискілер мен желіні бақылайды;
виртуализация иесі — гипервизор, ресурстарды бөлу, резервтеу және жүктемені көшіру мәселелерін қадағалайды;
СУБД иесі — базаның баптауларын, индекстерді, сұраныс жоспарларын және регламенттік жұмыстарды қамтамасыз етеді;
бизнес-ұстазы (business owner) — қандай жұмыс жылдамдығы қалыпты екенін және қандай операциялар критикалық екенін растайды;
инцидентті талдауды үйлестіруші — фактілерді жинайды, қадамдарды тағайындайды және талқылаудың жеке хат алмасуларға бөлінуіне жол бермейді.

Соңғы рөл әсіресе маңызды. Оған дейін мықты мамандар да ілініп қалуы мүмкін: сервер командасы хостқа қарап тұрады, виртуализация администраторы лимиттер мен oversubscription-ты тексереді, DBA ауыр сұраныстарды көреді, ал бизнес бір ауыздан «таңертең бәрі тежеледі» деп қайталайды. Бір адам керек, ол толық картинаны жинайды.

Алдын ала кім шешім қабылдайтынын және кім тек деректер беретінін жазып қою маңызды. DBA СУБД баптамаларын өзгертуді ұсынуы мүмкін, бірақ егер бұл сенімділік пен резервтеуге әсер етсе, шешім платформа иесінің арқылы өтулуі керек. Егер жобаға жүйелік интегратор немесе серверлік платформа өндірушісі қатысса да, басты ереже өзгермейді: әр қабат үшін нақты адам аты және жауап беру уақыты болуы тиіс.

Зре́л жобаны қарапайым белгі арқылы тануға болады. "Бірінші тексеретін кім?" деген сұраққа жылдам әрі аңғарымды жауап бар. "Вендор", "ИТ-бөлім" немесе "мердігер" емес, нақты рөл, шешімдер аумағы және эскалация тәртібі.

Енгізуден бұрын не туралы келісу керек

Системаның тез жұмыс істеуі керек деп айту жеткіліксіз. Алдын ала не қалыпты, не мәселе екендігін нақты көрсету қажет. Әйтпесе алғашқы ақауда әр тарап тек өз көзқарасына сүйенеді.

Бастапқыда қалыпты жүктемені тіркеу керек: бір уақытта қанша қолданушы жұмыс істейді, олар көбіне қандай операциялар орындайды, күн сайын қанша дерек өтеді, қай уақытта есептер құрылады, қай уақытта алмасулар мен резервтік көшірулер жүреді. Серверлер, виртуал орта және СУБД үшін бұл ресурстарды есептеу негізі болып табылады.

Сонымен қатар, баяу жұмысты қолданушы қалай көретінін сипаттау маңызды. "Төмен өнімділік" деп жазудың орнына анық белгілер көрсетіңіз: карточка 3 секундтан көп ашылады, есеп 1 минуттан ұзақ құрылады, кіру 20 секундтан артық уақыт алады. Сонда дау сезімдер туралы емес, нақты фактілер туралы болады.

Пик сағаттар мен маусымдық толқуларды бөлек көрсету қажет. Қызметкерлердің таңғы кіруі, ай соңындағы белсенділік, қабылдау кезеңі, салық кезеңі, құжаттардың жаппай шығару — бұлардың бәрі жүктемені өзгертеді. Мұндай пиктерді алдын ала есептемесеңіз, кейін оңайша жабдықты, гипервизорды немесе базаны кінәлай аласыз, ал қателік сценарийде болуы мүмкін.

Тағы бір маңызды тармақ — келісімсіз жасалмайтын өзгерістер тізімі. Жылдамдыққа тек сервер ауыстыруы ғана әсер етпейді. Көп жағдайда мәселені тыныш көрінетін түзетулер тудырады: виртуал машиналар арасында CPU және RAM-ды қайта бөлу, сақтау жүйесін ауыстыру, СУБД параметрлерін өзгерту, жаңартулар, жаңа қауіпсіздік тексерулерін қосу, түнгі тапсырмаларды жұмыс уақытында көшіру.

Барлығын қысқа жұмыс құжатына жинаған жөн. Онда базалық және пик жүктеме, баяу жұмыстың өлшенетін белгілері, жоғары жүктеме терезелері, келісуге жататын өзгерістер тізімі, жауап беру уақыты және инцидент кезінде қатысушылардың құрамы жеткілікті.

Мысалы, жүйе серверлік платформада, виртуал ортада және бөлек СУБД командасымен орналастырылған болса, мұндай құжат болмаған жағдайда тіпті бір таңғы ақау ұзақ хат алмасуға ауысуы мүмкін. Архитектурамен қатар жүктеме, өзгерістер және қателер кезінде әрекет ережелерін алдын ала келіскен әлдеқайда пайдалы.

Жауапкершілікті қадамдарға қалай бөлу керек

Жоба серверлер, виртуализация, СУБД және бизнес-қосымшадан тұратын кезде дау мына сценарий бойынша басталады: сервис уже баяу, ал әр қатысушы тек өз қабатын көреді. Бұл болдырмас үшін тексеру тізбегін алдын ала бөліп алу керек.

Алдымен бір жалпы сервис схемасы қажет. Әр команданың жеке схемаларының жиынтығы емес, біртұтас карта: пайдаланушы сұранысы, қосымша, дерекқор, виртуал машина, сақтау, желі және физикалық сервер. Тіпті бір бетті схема тәуелді тораптар мен әлсіз жерлерді бірден көрсетеді.

Одан кейін әр қабатқа иесі тағайындалуы керек. "Инфрақұрылым" деген жалпылық емес, тапсырманы қабылдайтын, өз бөлігін тексеріп, түсінікті жауап беретін нақты команда.

Тексеру тәртібі де алдын ала келісілген болуы тиіс:

Алдымен деградация фактісі жалпы метрикалар бойынша расталады, чаттағы шағымдарға сенбей.
Одан кейін қай жерде кідіріс өсіп жатқанын анықтайды: қосымша, дерекқор, виртуал машина, желі немесе диск.
Содан кейін әр иесі алдын ала келісілген көрсеткіштер жиынтығы бойынша өз қабатын тексереді.
Егер себеп оның зонасында болмаса, ол келесі командаға "барлығымызда бәрі жақсы" деген емес, тексерілген деректер мен қорытынды жібереді.
Үйлестіруші нәтижелерді бір картинаға жинайды және әрі қарай не тексерілетінін шешеді.

Ортақ метрикалар мен порогтарды бір құжатта ұстау пайдалы. Әдетте оларға жауап уақыты, CPU жүктемесі, дисктік жүйенің кешігуі, жад тұтынуы, негізгі SQL-сұраныстардың орындау уақыты, күту және рұқсат етілген төмендеу терезелері кіреді. Бұл көрсеткіштерді жай атау жеткіліксіз — жоба үшін нақты қандай мән қалыпты екенін алдын ала келісу маңызды.

Егер инфрақұрылым бірнеше қабат пен мердігерден тұрса, бұл әсіресе маңызды. Шын өмірдегі жобаларда мәселе сирек бір жерде болады. Жалпы схема және біртұтас тексеру тәртібі болмаса, кінәлі соңғы жауап берген адам болып қалуы мүмкін.

Жалпы құжатқа қандай метрикалар енгізу керек

Егер команда өнімділік жауапкершілігін шын мәнінде келісетін болса, құжат өлшенетін көрсеткіштерге сүйенуі тиіс. Әйтпесе алғашқы төмендеуде дау қайта басталады: серверде ме, виртуал машинада ма, желіде ме, әлде дерекқорда ма деген сияқты.

Ең түсінікті деңгей — қолданушыға жауап уақыты. Кіруге, карточканы ашуға, типтік операцияны орындауға және есепті құруға қанша уақыт рұқсат етілетінін жазу керек. Орташа ғана емес, шоғыр уақыттағы жоғарғы шекараны да тіркеу маңызды.

Келесі деңгей — платформа ресурстары. Физикалық түйін мен виртуал машиналар үшін әдетте CPU жүктемесі, жадтағы қор, лимиттерге ұрыну және мұндай күй ұзақтығы көрсетіледі. Бұл деректер жүйенің есептеу қуаты жеткілікті ме әлде мәселе басқа жерде ме екенін тез көрсетеді.

Дисктік жүйе мен желінің кешігулерін бөлек сипаттау қажет. Көп жағдайда платформалар шетіндегі ақаулар осында жасырынады: база жүктелгендей көрінеді, бірақ шын мәнінде ол дискіні күтуде немесе тораптар арасындағы желілік кешігулерге уақыт жоғалтып отыр.

Виртуализация үшін машиналардың параметрлерін нақты тіркеу пайдалы: vCPU саны, RAM көлемі, диск типі мен көлемі, overcommit ережелері, резервтеу, лимиттер мен басымдықтар. Осыныңсыз СУБД мінезін адал талқылау мүмкін емес — бірдей база әртүрлі шектеулері бар екі ВМ-де әртүрлі нәтиже көрсетеді.

СУБД үшін жүздеген көрсеткіш жинаудың қажеті жоқ. Барлық тарап түсінетін қысқа жиын жеткілікті: негізгі сұраныстардың орындау уақыты, блокировкалар саны, кезектер ұзындығы, буфер кэшінің қолданылуы, ұзақ операциялар саны және регламенттік тапсырмалардың терезелері.

Әр көрсеткіш үшін бес нәрсені бірден жазып қою пайдалы: қай жерде өлшенеді, немен жиналады, қандай мән қалыпты саналады, оны кім тексереді және қай кезеңде өлшеу дұрысырақ. Егер жүйе таңертең қызметкерлердің жаппай кіруін көтеруі керек болса, құжат дәл осы сценарийді сипаттауы тиіс, күн бойы орташа жүктемені емес.

Мысал: жүйе таңертең баяулайды

Үлгі жағдай келесідей: 9:00-11:00 аралығында қызметкерлер жүйеге жаппай кіреді, карточкаларды ашады, іздеу жүргізеді және құжаттарды басып шығарады. Қолдауға бірдей шағымдар түседі: беттер баяу ашылады, есептер ілініп қалады, кейде сессия бірнеше минут ойланады.

Алғашында әр команда тек өз кескінін көреді. Виртуализация сервер қолжетімді дейді. DBA база құлап кеткен жоқ деп жауап береді. Сақтау мамандары жүктеменің өскенін байқайды, бірақ оның дәл пайдаланушыларға кедергі жасайтынын дәлелдей алмайды.

Метрикалар бірге қарағанда картина айқындалады. Пик сағаттарда дерекқор орналасқан виртуал машина ресурс шегіне жетеді. Оған дәл сол сәтте процессор мен жадтың кепілдендірілген қуаты жетпейді. Сол уақытта сақтау жүйесінде кешігулер өседі, сондықтан оқу-жазу операциялары ұзарады. Осы жағдайда СУБД сұраныстар кезегін жинай бастайды.

Кестені тексеру тағы бір себебін көрсетеді: 9:15-те автоматты түрде ауыр есеп басталады. Ол үлкен көлемдегі деректі оқиды және қалыпты жұмыс операцияларымен сол ресурстар үшін бәсекелеседі.

Яғни, проблема бір жерде емес. Оның тізбегі: таңертеңгі қолданушы пигі, ВМ лимиттері, сақтау кешігулерінің өсуі және жоспарлы есептің сәтсіз уақыта басталуы.

Сондықтан ғана бірлескен тексеру көмектесті. Егер командалар жүйені жеке-жеке қарап кетсе, әрқайсысы картинаның бір бөлігін табар еді. Шешім де бірге келді: есеп басқа уақытқа ауыстырылды, ВМ-ге арналған лимиттер мен кепілдіктер қайта қаралды, ал сақтау жүйесінде пик сағаттар үшін рұқсат етілген кешігулер тіркелді. Шағымдар жоғалып кетті, себебі мәселе тізбек бойынша ашылды, біреу ғана өз бөлігін «жөндегендіктен» емес.

Жиі кездесетін қателер мен тұзақтар

Ең көп кездесетін қате қарапайым: әр команда тез "бізде бәрі қалыпты" дейді. Виртуализация администраторы жүктелген хостты көрмейді. СУБД командасы сұраныстар дұрыс жазылғанын көрсетеді. Сервер жеткізушісі жабдықта ақау таппайды. Бірақ қолданушы үшін жүйе әлі де баяу.

Осылайша өнімділікке жауапкершілік жоғалады. Мәселе бір қабатта емес, олардың арасында: ресурстарды бөлу, I/O кезектері, жад баптамалары, сақтау жүйесінің жауап уақыты немесе фондық тапсырмалардың кестесінде болуы мүмкін.

Алдын ала базалық өлшемдер алынбағаны да қауіпті. Егер ешкім жүйеге кіру қанша уақыт алатынын, есеп қалай тез құрыласын және таңертеңгі қалыпты жүктемені жазып қоймаса, кейін салыстыруға ештеңе болмайды. Кез келген талдау пікірлерге айналады.

Тағы бір тұзақ — бірден бірнеше параметрді өзгерту. Бір күнде ВМ жадын ұлғайтып, индекстерді қайта құрып, деректерді басқа сақтау жүйесіне көшіру жүйені шынында өзгертеді. Бірақ не көмектескенін анықтау мүмкін болмай қалады.

Көбіне соңғы шешімді қабылдау құқығын да ұмытады. Қорытынды шешімді бекітетін адам немесе топ болмаса, талқылау апталарға созылады. Бір мердігер CPU ұсынса, екіншісі СУБД баптауларын өзгертуді ұсынады, үшіншісі платформаның жаңартуын күте тұруды кеңес етеді.

Ең қымбатқа түсетін қателер жиыны: бастапқы метрикалардың болмауы, қабаттарды жекелей тексеру, бірден бірнеше өзгеріс енгізу, қабылдау критерийлерінің анық болмауы және қорытынды шешімді қабылдайтын адамның болмауы.

Қабылдауға да қатысты проблемалар аз емес. "Жылдам жұмыс істеуі тиіс" немесе "кешігусіз" сияқты жалпылама формулировкалар даулы отырыста көмектеспейді. Тек сандар ғана көмектеседі: форманың қанша секундта ашылатыны, жүйенің қанша қолданушыны ұстай алатыны және жауап уақытының қаншалықты өсуі рұқсат етілетіні.

Жақсы тест өте қарапайым: жаңа адам құжат ашып, бірден серверді кім тексеретінін, виртуализацияны кім қарайтынын, СУБД-ні кім тексеретінін және дау шыққан жағдайда шешімді кім қабылдайтынын түсіне ала ма? Егер жоқ болса, мәселе жобаны іске қоспас бұрын қойылған.

Іске қоспас бұрын қысқа чек-лист

Жоба іске қосылғанға дейін жүйенің жұмыс істейтінін тексеру ғана емес, кейін баяулау себептерін тез табуға болатын жағдайды қамтамасыз ету маңызды. Ол үшін қысқаша тізім жеткілікті:

инцидентті бір адам қабылдаған: факт жинайтын және жалпы статусқа жауап беретін;
нақты сандармен емес, жалпы ұғымдармен емес, метрикалар мен порогтар келісілген;
жұмысқа енгізбес бұрын типтік сценарийлер бойынша базалық өлшемдер алынған;
қабаттар бойынша эскалация тәртібі жазылған;
әрбір маңызды өзгерістен кейін қайта тексеру сценарийі бар.

Осындай чек-лист әдетте бір бетке сыяды, бірақ алғашқы маңызды инцидент кезінде көп сағаттарды үнемдейді. Егер жүйе қызметкерлер сменасының ашылуынан кейін әр таң сайын тежеліп жатса, командада уже бір ортақ бастау нүктесі болады: кім инцидентті жүргізеді, қандай сандарды қарау қажет және виртуализация мен СУБД-ны қандай тәртіппен тексеруге.

Келесі қадамдар

Келесі қадам қарапайым: әңгімеден нақты келісімдерге өту. Егер команда сервер, виртуализация және СУБД арасындағы мәселе туындауы мүмкін екенін түсінсе, кім бірінші, екінші және үшінші болып не тексеретінін бекітсін.

Көп жағдайда 30-40 минуттық қысқа кездесу жеткілікті. Қатысуы тиіс — нәтижеға шын әсер ететіндер: жүйе иесі, виртуал орта администраторы, СУБД маманы, сервер инженері және қосымша өкілі. Мақсат бір — жалпылама формулировкаларды алып тастап, әрекет тәртібі бойынша келісу.

Кездесуден кейін біртұтас жұмыс құжатын жинау қажет. Ол ондаған беттегі үлкен регламент емес, түсінікті кесте болуы керек: базалық метрика ретінде не есептеледі, оны кім жинайды, қайда сақталады, инцидентті кім бастайды, басқа командалар қашан қосылады және кім мәселе шешілді деп растайды.

Сонымен қатар жүйені жұмыста енгізбес бұрын жүктеме тестін жоспарлаған пайдалы. Ол әлсіз тұстарды алдын ала көрсетеді, әлі де баптауларды, ресурстарды немесе сервистердің орналастыру схемасын өзгертуге мүмкіндік бар кезде. Сондай-ақ CPU, жад, диск кешігулері, кезектер мен база мен қосымшаның жауап уақыты сияқты көрсеткіштерді кім жазып алатынын келісіп алу маңызды. Егер бұл қадам алдын ала тағайындалмаса, мәселе шыққан алғашқы сағаттар дәлелдерді жинаумен өтіп кетеді.

Жақсы ориентир келесідей көрінеді: 9:00-де жүйе тежелді, 9:10-ға дейін метрикалар жиналды, 9:20-ға дейін бастапқы тексеруді кім жүргізетіні анықталды, 10:00-ге дейін әрі қарайғы әрекет туралы жалпы шешім бар. Мұндай тәртіп командалар арасындағы дауларды айтарлықтай қысқартады.

Егер жоба серверлер, интеграция және бірнеше технологиялық қабаттарды қамтыса, жалпы картинаны көретін тарапты тартқан пайдалы. GSE.kz қатысатын жобаларда бұл дайындық сатысында әсіресе орынды: сервер жабдығы өндірушісі және жүйелік интегратор ретінде компания алдын ала инфрақұрылым, виртуализация және программалық бөлік бойынша рөлдерді бөліп қоюға көмектесе алады. Сонда жауапкершілік шекаралары іске қосар алдын анық болады.

Неғұрлым ерте бұл жасалса, алғашқы маңызды жүктеме кінә іздеуге емес, себепті тез талдауға айналуы ықтималдығы азаяды.