Баршаңызға жұма мүбарак болсын! Достар, бүгін біз курсқа арналған жарияланымдар сериясын жалғастырамыз , өйткені курстың жаңа тобында сабақтар келесі аптаның соңында басталады. Сонымен, бастайық!
Мониторинг – бұл жай ғана. Бұл белгілі факт. Nagios шақырыңыз, қашықтағы жүйеде NRPE іске қосыңыз, NRPE TCP 5666 портында Nagios конфигурациялаңыз және сізде бақылау бар.
Бұл соншалықты оңай, қызық емес. Енді сізде Nagios және NRPE үшін әдепкі бойынша жеткізілетін CPU уақыты, дискінің ішкі жүйесі, жедел жады үшін негізгі көрсеткіштер бар. Бірақ бұл іс жүзінде «бақылау» емес. Басы ғана.
(Әдетте олар PNP4Nagios, RRDtool және Thruk орнатады, Slack-те хабарландыруларды орнатады және тікелей nagioseexchange-ке барады, бірақ оны әзірге қалдырайық).
Жақсы мониторинг шын мәнінде өте күрделі, сіз шынымен бақылап отырған қолданбаның ішкі бөліктерін білуіңіз керек.
Бақылау қиын ба?
Кез келген сервер, ол Linux немесе Windows болсын, анықтамасы бойынша белгілі бір мақсатқа қызмет етеді. Apache, Samba, Tomcat, файлдарды сақтау, LDAP – бұл қызметтердің барлығы бір немесе бірнеше жағынан азды-көпті бірегей. Әрқайсысының өз қызметі, өзіндік ерекшеліктері бар. Сервер жүктелген кезде сізді қызықтыратын көрсеткіштерді, KPI (негізгі өнімділік көрсеткіштері) алудың әртүрлі жолдары бар.
Фотоның авторы туралы
(Менің бақылау тақталарым неон көк болғанын қалаймын - арманшыл күрсінді -... хмм...)
Қызметтерді ұсынатын кез келген бағдарламалық құралда көрсеткіштерді жинау механизмі болуы керек. Apache модулі бар mod-status, сервер күйі бетін көрсетеді. Nginx бар - stub_status. Tomcat-та негізгі көрсеткіштерді көрсететін JMX немесе пайдаланушы веб-қосымшалары бар. MySQL-де «жаһандық күйді көрсету» пәрмені және т.б.
Неліктен әзірлеушілер өздері жасайтын қолданбаларға ұқсас механизмдерді жасамайды?
Мұны тек әзірлеушілер жасай ма?
Көрсеткіштерді ендіруге белгілі бір немқұрайлылық деңгейі әзірлеушілермен шектелмейді. Мен Tomcat арқылы қосымшалар әзірлеген компанияларда жұмыс істедім және жалпы Tomcat қате журналдарын қоспағанда, өздерінің жеке көрсеткіштерін, қызмет көрсету әрекеттерінің журналдарын бермеді. Кейбір әзірлеушілер оларды таңғы 3:15-те оқу сәті болмаған жүйелік әкімшіге ештеңе білдірмейтін көптеген журналдар жасайды.
Фотоның авторы туралы
Мұндай өнімдерді шығаруға мүмкіндік беретін жүйелік инженерлер де жағдай үшін белгілі бір жауапкершілікті көтеруі керек. Жүйе инженерлерінің аздағанында журналдардан мағыналы көрсеткіштерді шығаруға тырысатын уақыты немесе қамқорлығы бар, бұл көрсеткіштердің мәтінмәнінсіз және оларды қолданба әрекеті аясында түсіндіру мүмкіндігі жоқ. Кейбіреулер «қазіргі уақытта бірдеңе дұрыс емес (немесе жақын арада) дұрыс емес» көрсеткіштерінен басқа, олардан қалай пайда көретінін түсінбейді.
Көрсеткіштерге қажеттілік туралы ойлаудың өзгеруі тек әзірлеушілер арасында ғана емес, сонымен қатар жүйелік инженерлер арасында да болуы керек.
Маңызды оқиғаларға жауап беріп қана қоймай, сонымен қатар олардың орын алмауын қамтамасыз етуді қажет ететін кез келген жүйелік инженер үшін метриканың болмауы әдетте бұған кедергі болып табылады.
Дегенмен, жүйелік инженерлер әдетте өз компаниясына ақша табу үшін кодпен араласпайды. Оларға проблемаларды анықтауда, өнімділік мәселелері туралы хабардарлықты арттыруда және т.б. жүйелер инженерінің жауапкершілігінің маңыздылығын түсінетін жетекші әзірлеушілер қажет.
Бұл нәрсені бұзады
Devops менталитеті даму (дев) мен операциялар (ops) ойлау арасындағы синергияны сипаттайды. «Девопс жасаймын» деген кез келген компания:
- олар жасамайтын нәрселерді айту ("Ханшайым қалыңдық" меміне сілтеме жасау - "Менің ойымша, бұл сіз ойлаған нәрсені білдірмейді!")
- Өнімді үздіксіз жақсарту көзқарасын көтермелеу.
Сіз өнімді жақсарта алмайсыз және оның қазіргі уақытта қалай жұмыс істейтінін білмесеңіз, оның жақсартылғанын біле алмайсыз. Егер сіз оның құрамдас бөліктерінің қалай жұмыс істейтінін, ол тәуелді қызметтерді, оның негізгі ауырсыну нүктелері мен кедергілерді түсінбесеңіз, өнімнің қалай жұмыс істейтінін біле алмайсыз.
Егер сіз ықтимал кедергілерді бақыламасаңыз, сіз Постмортем жазу кезінде «Бес неліктен» техникасын орындай алмайсыз. Өнімнің қалай жұмыс істейтінін көру немесе оның "қалыпты және бақытты" қалай көрінетінін білу үшін барлығын бір экранға қою мүмкін болмайды.
Солға, солға жылжытыңыз, МЕН ЛИЭЭ ДЕП АЙТТЫМ...
Мен үшін Devops-тың негізгі принциптерінің бірі – «солға ауысу». Осы контексте солға жылжыту мүмкіндікті ауыстыруды білдіреді (жауапкершілік жоқ, бірақ тек мүмкіндіктер) Жүйе инженерлері әдетте маңызды болатын нәрселерді орындау үшін, мысалы, өнімділік көрсеткіштерін жасау, журналдарды тиімдірек пайдалану және т.б., Бағдарламалық қамтамасыз етуді жеткізудің өмірлік циклінде солға қарай.
Фотоның авторы туралы
Бағдарламалық жасақтаманы әзірлеушілер оның барлық нысандарында, метрикасында, журналында, мониторинг интерфейсінде және ең бастысы, мониторингті жүзеге асыру үшін компания қолданатын бақылау құралдарын пайдалана білуі және білуі керек. олардың өнімі өндірісте қалай жұмыс істейтінін қараңыз. Сіз әзірлеушілерге көрсеткіштерді көрмейінше және олардың сыртқы түрін, өнім иесі оларды келесі брифингте CTO-ға қалай ұсынатынын және т.б. көрмейінше, бақылауға күш пен уақыт жұмсай алмайсыз.
Қысқаша айтқанда
- Атты суға апарыңыз. Әзірлеушілерге өздері үшін қаншалықты қиындықтардан аулақ бола алатынын көрсетіңіз, CTO айғайлаған өнім иесінің айқайы аз болуы үшін қолданбалары үшін дұрыс KPI және көрсеткіштерді анықтауға көмектесіңіз. Оларды ақырын және сабырлы түрде жарыққа әкеліңіз. Бұл жұмыс істемесе, қолданбалардан осы көрсеткіштерді алуды мүмкіндігінше тезірек жүзеге асыру үшін оларға немесе өнім иесіне пара беріңіз, қорқытыңыз және алдаңыз, содан кейін диаграммаларды сызыңыз. Бұл қиын болады, өйткені ол басымдық ретінде қарастырылмайды және өнімнің жол картасында кіріс әкелетін көптеген жобалар күтілуде. Сондықтан өнімге мониторингті енгізуге жұмсалған уақыт пен шығынды негіздеу үшін сізге іскерлік жағдай қажет болады.
- Жүйе инженерлеріне жақсы ұйықтауға көмектесіңіз. Шығарылатын кез келген өнім үшін «шығасын» бақылау тізімін пайдалану жақсы нәрсе екенін көрсетіңіз. Өндірістегі барлық қолданбалардың метрикамен қамтылғанына көз жеткізу әзірлеушілерге ненің дұрыс емес және қай жерде болып жатқанын көруге мүмкіндік беру арқылы түнде жақсы ұйықтауға көмектеседі. Дегенмен, кез келген әзірлеушіні, өнім иесін немесе CTO-ны тітіркендірудің және ренжітудің дұрыс жолы - табандылық пен қарсылық. Соңғы минутқа дейін қайта күтсеңіз, бұл әрекет кез келген өнімнің шығу күніне әсер етеді, сондықтан солға қайта жылжытыңыз және бұл мәселелерді жоба жоспарыңызға мүмкіндігінше тезірек енгізіңіз. Қажет болса, өнім жиналыстарына барыңыз. Жалған мұртты және киізді немесе басқа нәрсені киіңіз, ол ешқашан сәтсіздікке ұшырамайды. Мазасыздықтарыңызды жеткізіңіз, нақты артықшылықтарды көрсетіңіз және уағыздаңыз.
- Әзірлеу (әзірлеу) және операциялар (операциялар) қызыл аймаққа ауысатын өнім көрсеткіштерінің мәні мен салдарын түсінетініне көз жеткізіңіз. Ops-ті өнім денсаулығының жалғыз қамқоршысы ретінде қалдырмаңыз, әзірлеушілер де қатысқанына көз жеткізіңіз (#productsquads).
- Журналдар тамаша нәрсе, бірақ метрика да. Оларды біріктіріп, бөренелеріңіздің үлкен жалын шарында қоқысқа айналуына жол бермеңіз. Әзірлеушілерге олардың журналдарын неге басқа ешкім түсінбейтінін түсіндіріңіз және көрсетіңіз, таңғы 3:15-те пайдасыз журналдарды қараудың қандай екенін көрсетіңіз.
Фотоның авторы туралы
Бар болғаны. Жаңа материал келесі аптада шығады. Курс туралы көбірек білгіңіз келсе, біз сізді шақырамыз , ол дүйсенбі күні өтеді. Енді дәстүрлі түрде пікірлеріңізді күтеміз.
Ақпарат көзі: www.habr.com