Систем нь илүү төвөгтэй байх тусам бүх төрлийн сэрэмжлүүлгээр дүүрдэг. Эдгээр сэрэмжлүүлэгт хариу үйлдэл үзүүлж, нэгтгэж, нүдээр харуулах шаардлагатай байна. Энэ бол олон хүнд сандартал танил болсон нөхцөл байдал гэж би бодож байна.
Хэлэлцэх шийдэл нь хамгийн гэнэтийн зүйл биш боловч хайлт нь энэ сэдвээр бүрэн хэмжээний нийтлэл гарч ирэхгүй.
Тиймээс би FunCorp-ийн туршлагаас хуваалцаж, үүргийн үйл явц хэрхэн зохион байгуулагдсан, хэн дууддаг, яагаад, хэрхэн харж болох талаар ярихаар шийдсэн.
PagerDuty гэж юу вэ?
Тиймээс эдгээр бүх асуудлыг шийдэхийн тулд бид тохиромжтой хэрэгсэл хайж эхэлсэн. Хэсэг хайсны эцэст бид PagerDuty-г сонгосон. PD нь олон тооны интеграцчлал, тохиргоотой нэлээд бүрэн бөгөөд товч шийдэл мэт санагдсан. Тэр ямархуу хүн бэ?
Товчхондоо, PagerDuty нь янз бүрийн интеграцчлалаар дамжуулан ирж буй ослыг боловсруулах, жижүүрийн захиалга өгөх, дараа нь ослын түвшингээс хамааран (өндөр түвшинд - дуудлага, доод түвшинд -) жижүүрийн инженерийг сэрэмжлүүлэх боломжтой осол боловсруулах платформ юм. програм / SMS-ээс түлхэх).
Жижүүр гэж хэн бэ?
Энэ нь магадгүй PD-г тохируулах анхны газар юм.
FunCorp-д бусад компаниудын нэгэн адил жижүүрийн хүндэт албан тушаал байдаг. Өдөрт нэг удаа инженерээс инженер рүү дамждаг. PagerDuty-ийн сэрэмжлүүлэгт хариу өгөх эхний болон хоёр дахь мөр гэж нэрлэгддэг. Өндөр ач холбогдолтой дохио ирсэн гэж бодъё, хэрэв эхний шугамаас жижүүр рүү залгаснаас хойш 10 минутын дараа ямар ч хариу үйлдэл үзүүлэхгүй (өөрөөр хэлбэл хүлээн зөвшөөрсөн эсвэл шийдвэрлэсэн статус руу шилжүүлээгүй) дуудлага хоёрдугаарт очно гэж бодъё. үүрэг инженер. Үүнийг PagerDuty-д Өргөтгөх бодлогоор тохируулсан болно.
Хоёр дахь жижүүр хариу өгөхгүй бол мэдэгдэл буцаж ирнэ гол жижүүрт.
Тиймээс аливаа ирж буй өндөр ач холбогдолтой сэрэмжлүүлэг боловсруулагдаагүй хэвээр үлдэж чадахгүй.
Одоо тохиолдлууд хаанаас гарч болохыг харцгаая.
Бид ямар интеграцийг ашигладаг вэ?
PD нь янз бүрийн үйлчилгээнээс олон янзын тохиолдлыг хүлээн авдаг. Бид одоогоор 25 орчим ийм үйлчилгээтэй бөгөөд тэдгээрийг боловсруулахын тулд бид бэлэн интеграцийг ашигладаг.
- Prometheus
Метрик цуглуулах гол систем бол Prometheus юм. Хабре дээр энэ талаар маш их зүйл бичсэн байгаа, бид өөр өөр орчинд зориулагдсан хэд хэдэн зүйл байгаа гэдгийг л хэлье: нэг нь виртуал машин болон докеруудаас хэмжигдэхүүнүүдийг цуглуулдаг, нөгөө нь Amazon үйлчилгээнээс, гурав дахь нь техник хангамжийн машинуудаас цуглуулдаг. Телеграфыг голчлон хэмжүүр экспортлогч болгон ашигладаг.
- И-мэйл
Энд ч гэсэн гарчигнаас бүх зүйл тодорхой харагдаж байна гэж бодож байна. Энэ интеграци нь cron-оор гүйцэтгэгдсэн зарим скриптээс мэдэгдэл илгээхэд ашиглагддаг. PD танд захидал илгээх тодорхой хаягийг өгдөг. Ийм интеграци бүхий үйлчилгээг бий болгохдоо та тэргүүлэх чиглэл, ирж буй тохиолдлуудыг ямар дарааллаар боловсруулах, сэрэмжлүүлгийг хэрхэн яаж үүсгэх (ирж буй захидал, ирж буй захидал + тодорхой дүрэм гэх мэт) тохируулж болно.
- Сул
Миний бодлоор маш сонирхолтой интеграци. Ямар нэг зүйл тохиолдсон ч үйл явдалд хамрагдахгүй байх тохиолдол байдаг. Тиймээс бид осол үүсгэхийн тулд Slack-ийн интеграцийг нэмсэн. Өөрөөр хэлбэл, та корпорацийн Slack руу бичиж болно /callofduty бүх зүйл удаан, удахгүй эвдэрнэ мөн ПД үүнийг боловсруулж, болсон явдлыг жижүүрийн инженер рүү илгээнэ.
Бид хийдэг:
Бид харж байна:
- API
HTTP интеграци. Үнэндээ энд онцгой сонирхолтой зүйл байхгүй, зүгээр л JSON форматтай биетэй POST хүсэлт байна. Жишээлбэл, сонирхолтой зүйл бол бид үүнийг гадны хяналтанд ашигладаг . Энэхүү үйлчилгээ нь дэлхийн өнцөг булан бүрээс манай сайтуудын хүртээмжийг шалгадаг. Бид хүлээн зөвшөөрөх боломжгүй хариу код хүлээн авсан тохиолдолд (жишээлбэл, 502) осол үүсч, дараа нь бүх зүйл дээр дурдсан гинжин хэлхээний дагуу явагдана. StatusCake нь өөрөө дотоод URL, SSL сертификат эсвэл домэйн дуусах хугацааг хянах чадвартай.
- LibreNMS
Энэ бол өөр нэг хяналтын систем бөгөөд та энэ талаар тэдний вэбсайтаас уншиж болно . Үүний тусламжтайгаар бид серверүүдээс сүлжээний интерфейс болон iDRAC-ыг хянадаг.
Мөн Datadog, CloudWatch гэх мэт интеграцчлалууд байсан. Та тэдэнд юу тохиолдсон талаар илүү ихийг харж болно .
Дүрслэх
Ослын мэдээлэх гол систем нь Slack юм. PD-д ирж буй бүх тохиолдлыг тусгай чатад бичдэг бөгөөд хэрэв статус нь өөрчлөгдвөл энэ нь чат дээр харагдана.
Таазнаас өлгөөтэй мониторуудын дэлгэцэн дээр хэрэгтэй мэдээллийг харуулах боломж гарч ирэхэд бид (devops хэлтэст) тэдэнд харуулах зүйл байхгүй гэдгийг гэнэт ойлгов. Гайхамшигтай Графана байдаг, гэхдээ энэ нь бүх зүйлийг хамардаггүй бөгөөд ажилтнууд график биш харин сэрэмжлүүлэгт хариу үйлдэл үзүүлдэг.
PD-д зориулсан товч бөгөөд мэдээлэл сайтай "самбар"-ыг GitHub дээр сайтар хайсан боловч амжилтгүй болсны дараа бид зөвхөн хэрэгтэй зүйлээ бичихээр шийдсэн. Хэдийгээр эхлээд PD интерфэйсийг өөрөө харуулах санаа байсан ч энэ нь бүр ч эвгүй харагдаж байв.
Үүнийг бичихийн тулд танд зөвхөн унших эрхтэй PD-ээс түлхүүр авахад л хангалттай.
Энэ бол бидний авсан зүйл юм:
Дэлгэц нь одоогийн нээлттэй осол, сонгосон хуваарийн дагуу одоо ажиллаж байгаа жижүүрийн инженерийн нэр, өндөр ач холбогдолтой осол аваагүй цагийг харуулна (өндөр ач холбогдолтой осол гарсан самбарыг улаанаар тодруулна).
.
Үүний үр дүнд бид бүх тохиолдлуудыг үзэхэд тохиромжтой хяналтын самбар авсан. Хэрэв та нарын зарим нь бидний туршлага хэрэгтэй гэж үзвэл би баяртай байх болно.
Эх сурвалж: www.habr.com