Бүгдэд нь Баасан гарагийн мэнд хүргэе! Найзууд аа, өнөөдөр бид курст зориулсан цуврал нийтлэлүүдийг үргэлжлүүлж байна , учир нь тус курсын шинэ бүлгийн хичээл ирэх долоо хоногийн сүүлээр эхлэх болно. За, эхэлцгээе!
Хяналт нь зүгээр л. Энэ бол мэдэгдэж байгаа баримт юм. Nagios-г авчирч, алсын систем дээр NRPE-г ажиллуулж, NRPE TCP порт 5666 дээр Nagios-ийг тохируулж, танд хяналт тавих болно.
Энэ нь тийм ч хялбар, тийм ч сонирхолтой биш юм. Одоо та Nagios болон NRPE-д анхдагчаар нийлүүлэгдсэн CPU-ийн цаг, дискний дэд систем, RAM-ийн үндсэн хэмжигдэхүүнтэй боллоо. Гэхдээ энэ нь үнэндээ "хяналт" биш юм. Энэ бол дөнгөж эхлэл.
(Ихэвчлэн тэд PNP4Nagios, RRDtool, Thruk програмуудыг суулгаж, Slack дээр мэдэгдлүүдийг суулгаж, шууд nagioseexchange руу очдог, гэхдээ одоохондоо үүнийг орхиё).
Сайн хяналт Энэ нь үнэндээ нэлээд төвөгтэй тул та хянаж буй програмынхаа дотоод байдлыг мэдэх хэрэгтэй.
Хяналт нь хэцүү юу?
Линукс ч бай Windows ч бай ямар ч сервер тодорхой зорилготойгоор үйлчилнэ. Apache, Samba, Tomcat, файл хадгалах, LDAP - эдгээр бүх үйлчилгээ нь нэг буюу хэд хэдэн талаараа өвөрмөц юм. Тус бүр өөрийн гэсэн функцтэй, өөрийн гэсэн онцлогтой. Сервер ачаалалтай үед танд сонирхолтой хэмжигдэхүүн, KPI (үйл ажиллагааны гол үзүүлэлт) авах янз бүрийн арга байдаг.
Зургийн зохиогч тухай
(Миний хяналтын самбарууд неон цэнхэр байгаасай - мөрөөдөмтгий санаа алдаад -... хмм...)
Үйлчилгээ үзүүлдэг аливаа програм хангамж нь хэмжүүр цуглуулах механизмтай байх ёстой. Apache нь модультай mod-status, серверийн статусын хуудсыг харуулж байна. Nginx нь - stub_status. Tomcat нь үндсэн хэмжүүрүүдийг харуулдаг JMX эсвэл захиалгат вэб програмуудтай. MySQL нь "дэлхийн статусыг харуулах" гэх мэт командтай.
Тэгвэл яагаад хөгжүүлэгчид өөрсдийн үүсгэсэн аппликешнүүдэд ижил төстэй механизмуудыг суулгадаггүй юм бэ?
Үүнийг зөвхөн хөгжүүлэгчид хийдэг үү?
Хэмжилтийг оруулахад тодорхой хэмжээний хайхрамжгүй хандах нь зөвхөн хөгжүүлэгчдэд хязгаарлагдахгүй. Би Tomcat ашиглан програм хөгжүүлдэг компаниудад ажиллаж байсан бөгөөд ерөнхий Tomcat алдааны бүртгэлээс бусад өөрсдийн хэмжүүр, үйлчилгээний үйл ажиллагааны бүртгэлийг оруулаагүй. Зарим хөгжүүлэгчид өглөөний 3:15 минутад уншсан азгүй системийн администраторт ямар ч утгагүй олон бүртгэл үүсгэдэг.
Зургийн зохиогч тухай
Ийм бүтээгдэхүүнийг гаргах боломжийг олгодог системийн инженерүүд нөхцөл байдалд тодорхой хэмжээний хариуцлага хүлээх ёстой. Цөөн тооны системийн инженерүүд эдгээр хэмжигдэхүүнүүдийн контекст, хэрэглээний үйл ажиллагааны хүрээнд тэдгээрийг тайлбарлах чадваргүйгээр логуудаас утга учиртай хэмжигдэхүүнүүдийг гаргаж авахыг оролдох цаг зав, анхаарал халамжтай байдаг. Зарим нь "Одоо ямар нэг зүйл буруу байна (эсвэл удахгүй болно)" гэсэн үзүүлэлтээс бусад нь үүнээс хэрхэн ашиг тус хүртэж болохыг ойлгодоггүй.
Хэмжилтийн хэрэгцээний талаархи сэтгэлгээний өөрчлөлт нь зөвхөн хөгжүүлэгчид төдийгүй системийн инженерүүдийн дунд байх ёстой.
Зөвхөн чухал үйл явдлуудад хариу үйлдэл үзүүлэхээс гадна тэдгээр нь тохиолдохгүй байхыг баталгаажуулах шаардлагатай аливаа системийн инженерийн хувьд хэмжүүрийн дутагдал нь ихэвчлэн үүнийг хийхэд саад болдог.
Гэсэн хэдий ч системийн инженерүүд ихэвчлэн компанидаа мөнгө олохын тулд код ашигладаггүй. Асуудлыг тодорхойлох, гүйцэтгэлийн асуудлын талаарх мэдлэгийг дээшлүүлэх гэх мэт системийн инженерийн үүрэг хариуцлагын чухлыг ойлгодог тэргүүлэх хөгжүүлэгчид тэдэнд хэрэгтэй.
Энэ сэтгэл хөдөлгөм зүйл
Devops сэтгэхүй нь хөгжил (dev) болон үйл ажиллагааны (ops) сэтгэлгээний хоорондын уялдаа холбоог тодорхойлдог. "Devops хийдэг" гэж байгаа аливаа компани дараахь зүйлийг хийх ёстой.
- тэдний хэлэхгүй байж магадгүй зүйлийг хэлэх ("Гүнжийн сүйт бүсгүй" дурсамжийг дурдаж байна - "Энэ нь таны бодож байгаа зүйл гэсэн үг биш гэж би бодохгүй байна!")
- Бүтээгдэхүүнийг тасралтгүй сайжруулах хандлагыг урамшуулах.
Та ямар нэгэн бүтээгдэхүүн хэрхэн ажиллаж байгааг мэдэхгүй бол сайжруулж, сайжруулсан гэдгийг мэдэж чадахгүй. Хэрэв та түүний бүрэлдэхүүн хэсгүүд хэрхэн ажилладаг, ямар үйлчилгээнээс хамаардаг, гол өвдөлтийн цэгүүд, саад тотгорыг ойлгохгүй бол бүтээгдэхүүн хэрхэн ажилладагийг мэдэх боломжгүй.
Хэрэв та болзошгүй саад бэрхшээлийг ажиглахгүй бол үхлийн дараах бичлэгийг бичихдээ "Таван яагаад" техникийг дагаж мөрдөх боломжгүй болно. Та бүтээгдэхүүн хэрхэн ажилладагийг харах эсвэл "хэвийн бөгөөд аз жаргалтай" гэж юу болохыг мэдэхийн тулд бүгдийг нэг дэлгэц дээр байрлуулах боломжгүй болно.
Зүүн, зүүн, БИ ЛЭЭЕ гэж хэлсэн
Миний хувьд Devops-ийн гол зарчмуудын нэг бол "зүүн шилжих" юм. Энэ нөхцөлд зүүн тийш шилжих нь боломжийг шилжүүлэх гэсэн үг юм (хариуцлага байхгүй, гэхдээ зөвхөн чадавхи) програм хангамжийн ашиглалтын мөчлөгийн зүүн талд гүйцэтгэлийн хэмжүүр үүсгэх, бүртгэлийг илүү үр дүнтэй ашиглах гэх мэт системийн инженерүүдийн ихэвчлэн анхаардаг зүйлсийг хийх.
Зургийн зохиогч тухай
Програм хангамж хөгжүүлэгчид нь бүх хэлбэр, хэмжүүр, бүртгэл, хяналтын интерфейс, хамгийн чухал нь хяналт тавихын тулд компанийн ашигладаг хяналтын хэрэгслийг ашиглаж, мэддэг байх ёстой. Тэдний бүтээгдэхүүн үйлдвэрлэлд хэрхэн ажиллаж байгааг хараарай. Та хөгжүүлэгчид хэмжүүрүүдийг харж, тэдний харагдах байдал, бүтээгдэхүүний эзэмшигч нь дараагийн товч танилцуулга дээр CTO-д хэрхэн танилцуулах гэх мэтийг харах хүртэл хяналтанд хүчин чармайлт, цаг зарцуулж чадахгүй.
Товчхон ярьдаг
- Морио ус руу хөтөл. Хөгжүүлэгчид өөрсдөдөө ямар их бэрхшээлээс зайлсхийж болохыг харуулж, тэдний хэрэглээний зөв KPI болон хэмжигдэхүүнийг тодорхойлоход нь тусал, ингэснээр CTO-оос хашгирч буй бүтээгдэхүүний эзэмшигчийн хашгиралт бага байх болно. Тэднийг зөөлөн, тайван байдлаар гэрэлд аваач. Хэрэв энэ нь ажиллахгүй бол тэдгээрийг эсвэл бүтээгдэхүүний эзэмшигчийг хахуульдаж, заналхийлж, хууран мэхэлж, эдгээр хэмжигдэхүүнийг програмаас аль болох хурдан авахын тулд диаграммыг зур. Энэ нь нэн тэргүүний зорилт гэж үзэхгүй бөгөөд бүтээгдэхүүний замын зурагт орлого олох олон төсөл хүлээгдэж байгаа тул энэ нь хэцүү байх болно. Тиймээс, танд хяналт тавихад зарцуулсан цаг хугацаа, зардлыг зөвтгөх бизнесийн хэрэг хэрэгтэй болно.
- Системийн инженерүүдэд сайн унтаж амрахад нь туслаарай. Гаргаж буй аливаа бүтээгдэхүүнд "зайлцгаая" шалгах хуудсыг ашиглах нь сайн хэрэг гэдгийг тэдэнд харуул. Үйлдвэрлэлийн бүх программыг хэмжүүрээр бүрхсэн байх нь хөгжүүлэгчдэд юу болж, хаана байгааг харах боломжийг олгосноор шөнийн цагаар илүү сайн унтахад тусална. Гэсэн хэдий ч аливаа хөгжүүлэгч, бүтээгдэхүүний эзэмшигч, CTO-г бухимдуулж, бухимдуулах зөв арга бол тууштай байж, эсэргүүцэх явдал юм. Хэрэв та эцсийн мөч хүртэл дахин хүлээх юм бол энэ үйлдэл нь аливаа бүтээгдэхүүний гарах огноонд нөлөөлөх тул зүүн тийш дахин шилжүүлж, эдгээр асуудлыг төслийн төлөвлөгөөнд аль болох хурдан оруулаарай. Шаардлагатай бол бүтээгдэхүүний уулзалтууд руу яваарай. Хуурамч сахал, эсгий эсвэл ямар нэгэн зүйл өмс, энэ нь хэзээ ч бүтэхгүй. Санаа зовоож буй асуудлаа илэрхийлж, тодорхой ашиг тусыг үзүүлж, сайн мэдээг түгээ.
- Хөгжүүлэлт (хөгжүүлэлт) болон үйл ажиллагаа (үйл ажиллагаа) хоёулаа улаан бүсэд шилжих бүтээгдэхүүний хэмжүүрийн утга, үр дагаврыг ойлгож байгаа эсэхийг шалгаарай. Ops-ийг бүтээгдэхүүний эрүүл мэндийн цорын ганц хамгаалагч гэж бүү орхи, хөгжүүлэгчид ч гэсэн оролцож байгаа эсэхийг шалгаарай (#productsquads).
- Лог бол гайхалтай зүйл боловч хэмжүүрүүд ч мөн адил. Тэдгээрийг нэгтгэж, таны гуалиныг ашиггүй байдлын асар том галын бөмбөгөнд хог болгохыг бүү зөвшөөр. Яагаад өөр хэн ч тэдний бүртгэлийг ойлгохгүй байдгийг тайлбарлаж, хөгжүүлэгчдэд үзүүлээрэй, өглөөний 3:15 цагт хэрэггүй логуудыг харах ямар байдгийг тэдэнд үзүүлээрэй.
Зургийн зохиогч тухай
Тэгээд л болоо. Ирэх долоо хоногт шинэ материал гарна. Хэрэв та сургалтын талаар илүү ихийг мэдэхийг хүсвэл бид таныг урьж байна , энэ нь даваа гарагт болох юм. Одоо бид уламжлал ёсоор таны сэтгэгдлийг хүлээж байна.
Эх сурвалж: www.habr.com