Баарыңыздарга жума мубарак болсун! Достор, бүгүн биз курска арналган басылмалардын сериясын улантабыз , анткени курстун жаңы группасында сабактар кийинки жуманын аягында башталат. Ошентип, баштайлы!
Мониторинг болуп саналат так. Бул белгилүү факт. Nagiosду алып келиңиз, алыскы системада NRPE иштетиңиз, NRPE TCP 5666 портунда Nagios конфигурациялаңыз жана сизде мониторинг бар.
Бул абдан оңой, кызык эмес. Эми сизде демейки боюнча Nagios жана NRPEге берилген CPU убактысы, дисктин подсистемасы, RAM үчүн негизги көрсөткүчтөр бар. Бирок бул иш жүзүндө "мониторинг" эмес. Бул башталышы гана.
(Көбүнчө алар 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) ой жүгүртүү ортосундагы синергетиканы сүрөттөйт. "Девопс жасайм" деген компания төмөнкүлөргө милдеттүү:
- алар мүмкүн болбогон нерселерди айтуу (The Princess Bride мемине шилтеме кылуу - "Менимче, бул сиз ойлогон нерсени билдирет деп ойлобойм!")
- Продукцияны тынымсыз жакшыртууга болгон мамилени кубаттоо.
Сиз өнүмдү өркүндөтө албайсыз жана ал азыр кандайча иштээрин билбесеңиз, анын жакшыртылганын биле албайсыз. Эгерде сиз анын компоненттеринин кантип иштээрин, ал көз каранды кызматтарды, анын негизги ооруу жерлерин жана тоскоолдуктарын түшүнбөсөңүз, анын кантип иштээрин биле албайсыз.
Эгерде сиз мүмкүн болгон тоскоолдуктарды байкабасаңыз, анда "Постмортем" жазууда "Беш эмне үчүн" техникасын колдоно албайсыз. Продукт кандайча иштээрин көрүү же анын "кадимки жана бактылуу" экенин билүү үчүн баарын бир экранга кое албайсыз.
Солго жылдыруу, СОЛ, МЕН ЛЕЭЭ ДЕДИ...
Мен үчүн Devopsтун негизги принциптеринин бири – “солго жылдыруу”. Бул контекстте солго жылдыруу мүмкүнчүлүгүн өзгөртүү дегенди билдирет (жоопкерчилик жок, бирок мүмкүнчүлүктөр гана) системалык инженерлер адатта кам көрүүчү иштерди аткаруу үчүн, мисалы, натыйжалуулук көрсөткүчтөрүн түзүү, журналдарды натыйжалуураак колдонуу ж.
Сүрөттүн автору боюнча
Программалык камсыздоону иштеп чыгуучулар компаниянын бардык формаларында, метрикасында, журналында, мониторинг интерфейсинде жана эң негизгиси мониторинг жүргүзүү үчүн колдонгон мониторинг куралдарын колдоно билиши жана билүүсү керек. алардын продуктусу өндүрүштө кандай иштээрин карагыла. Иштеп чыгуучулар метрикаларды көрүп, алардын сырткы көрүнүшүнө, өнүм ээси аларды кийинки брифингде CTOго кандайча көрсөткөнүнө жана башкаларга таасир этмейинче, мониторинг жүргүзүүгө күч жана убакыт жумшай албайсыз.
Кыскача айтканда
- Атыңды сууга жетеле. Иштеп чыгуучуларга өздөрү үчүн канчалык кыйынчылыктан кутула аларын көрсөтүңүз, CTO тарабынан кыйкырып жаткан продукт ээсинин кыйкырыгы азыраак болушу үчүн, алардын тиркемелери үчүн туура KPI жана метрикаларды аныктоого жардам бериңиз. Аларды жарыкка акырын жана тынч алып келгиле. Эгер бул иштебесе, анда аларды же продукт ээсин пара берип, коркутуп, кыйнап, бул көрсөткүчтөрдү тиркемелерден мүмкүн болушунча тезирээк ишке ашыруу үчүн, анан диаграммаларды тартыңыз. Бул кыйын болот, анткени ал артыкчылык катары каралбайт жана продуктунун жол картасында көптөгөн киреше алып келүүчү долбоорлор күтүлөт. Ошондуктан, продуктка мониторинг жүргүзүүгө сарпталган убакытты жана чыгымды актоо үчүн сизге бизнес иши керек болот.
- Системанын инженерлерине жакшы уктоого жардам бериңиз. Чыгарылып жаткан ар бир продукт үчүн "келгиле, чыгаралы" текшерүү тизмесин колдонуу жакшы нерсе экенин көрсөтүңүз. Өндүрүштөгү бардык тиркемелер метрика менен камтылганын текшерүү, иштеп чыгуучуларга эмне туура эмес болуп жатканын жана кайда жатканын көрүүгө мүмкүнчүлүк берип, түнкүсүн жакшы уктоого жардам берет. Бирок, ар кандай иштеп чыгуучунун, продуктунун ээсин же CTOнун кыжырын келтирип, нааразы кылуунун эң туура жолу - бул өжөрлүк жана каршы туруу. Бул жүрүм-турум, эгер сиз дагы бир жолу акыркы мүнөткө чейин күтө турган болсоңуз, кандайдыр бир продукттун чыгарылган күнүнө таасирин тийгизет, андыктан кайра солго жылдырып, бул маселелерди долбоордун планына мүмкүн болушунча тезирээк киргизиңиз. Зарыл болсо, продукт жолугушууларга жол. Жасалма мурут, кийиз же башка нерсе кийиңиз, ал эч качан бузулбайт. Көйгөйлөрүңүздү айтыңыз, ачык-айкын пайдаларды көрсөтүңүз жана жакшы кабарды таратыңыз.
- Өнүмдүн көрсөткүчтөрүнүн кызыл зонага өтүү маанисин жана натыйжасын иштеп чыгуу (иштеп чыгуу) жана операциялар (иштер) түшүнүшүн камсыз кылыңыз. Ops'ту өнүмдөрдүн ден соолугунун жалгыз камкорчусу катары калтырбаңыз, иштеп чыгуучулар да катышканын текшериңиз (#productsquads).
- Журналдар сонун нерсе, бирок метрика да ошондой. Аларды айкалыштырыңыз жана журналдарыңыз пайдасыздыктын чоң жалындаган шарында таштанды болуп калышына жол бербеңиз. Иштеп чыгуучуларга алардын журналдарын эмне үчүн башка эч ким түшүнбөй турганын түшүндүрүңүз жана көрсөтүңүз, таңкы саат 3:15те пайдасыз журналдарды көрүү кандай экенин көрсөтүңүз.
Сүрөттүн автору боюнча
Баары болду. Жаңы материал кийинки аптада чыгат. Курс жөнүндө көбүрөөк билгиңиз келсе, биз сизди чакырабыз , Дүйшөмбү күнү болот. Эми биз салттуу түрдө сиздин пикириңизди күтөбүз.
Source: www.habr.com