Би SRE инженер дадлагажигчаар долоо хоногийг хэрхэн өнгөрүүлсэн. Програм хангамжийн инженерийн нүдээр үүрэг

Би SRE инженер дадлагажигчаар долоо хоногийг хэрхэн өнгөрүүлсэн. Програм хангамжийн инженерийн нүдээр үүрэг

SRE инженер - дадлагажигч

Эхлээд би өөрийгөө танилцуулъя. би - @tristan.read, группын урд талын инженер Монитор:: Эрүүл мэнд GitLab. Өнгөрсөн долоо хоногт би манай дуудлагаар ажилладаг SRE инженерүүдийн нэгтэй дадлага хийх нэр төрийн хэрэг байлаа. Зорилго нь жижүүрийн өдөр тутмын үйл явдалд хэрхэн хариу үйлдэл үзүүлж байгааг ажиглаж, ажил дээрээ бодит туршлага хуримтлуулах явдал байв. Бид инженерүүдээ хэрэглэгчийн хэрэгцээг илүү сайн ойлгохыг хүсч байна функцууд Монитор:: Эрүүл мэнд.

Би долоо хоногийн турш SRE инженерийг хаа сайгүй дагаж мөрдөх шаардлагатай болсон. Өөрөөр хэлбэл, би хүлээлгэн өгөх үеэр байлцаж, ижил дохиоллын сувгуудыг хянаж, зөрчил гарсан тохиолдолд хариу үйлдэл үзүүлсэн.

Үйл явдал

Долоо хоногийн дотор 2 хэрэг гарсан.

1. Крипто олборлогч

GitLab.com лхагва гарагт ашиглалтын өсөлтийг харлаа GitLab Runner'a, гүйлтийн минутыг ашиглан криптовалют олборлох оролдлогоос үүдэлтэй. Уг үйл явдлыг манай зөрчлийг саармагжуулах хэрэгслийг ашиглан шийдвэрлэсэн бөгөөд энэ нь гүйгчийн даалгаврыг зогсоож, түүнтэй холбоотой төсөл болон бүртгэлийг устгадаг.

Хэрэв энэ үйл явдлыг анзаараагүй бол автомат хэрэгсэл үүнийг барьж авах байсан ч энэ тохиолдолд SRE инженер зөрчлийг хамгийн түрүүнд анзаарсан. Ослын даалгавар үүсгэсэн боловч энэ талаарх мэдээлэл хаалттай байна.

2. Canary болон Үндсэн хэрэглээний гүйцэтгэлийн бууралт

Энэ явдал удаашрал, Gitlab.com дээрх канар болон үндсэн вэб програмын алдааны давтамж нэмэгдсэнтэй холбоотой юм. Хэд хэдэн Apdex утгыг зөрчсөн.

Нээлттэй тохиолдлын даалгавар: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

Гол олдворууд

Би жижүүрийн долоо хоногт сурсан хэдэн зүйлийг энд оруулав.

1. Сэрэмжлүүлэг нь нормоос хазайлтыг илрүүлэхэд хамгийн ашигтай байдаг.

Сэрэмжлүүлгийг хэд хэдэн төрөлд хувааж болно:

  • "Секундэд 10 5xx алдаа гарлаа" гэх мэт тодорхой босго утгад суурилсан сэрэмжлүүлэг.
  • "Тухайн үеийн хүсэлтийн нийт эзлэхүүний 5%-д ногдох 10xx алдааны давтамж" гэх мэт босго нь хувийн үзүүлэлт болох сэрэмжлүүлэг.
  • "5-р хувь дахь 90xx алдаа" гэх мэт түүхэн дундаж дээр үндэслэсэн сэрэмжлүүлэг.

Ерөнхийдөө 2 ба 3-р төрлүүд нь жижүүрийн SRE-д илүү ашигтай байдаг, учир нь тэдгээр нь үйл явц дахь нормоос хазайлтыг илрүүлдэг.

2. Олон сэрэмжлүүлэг хэзээ ч осолд хүргэдэггүй.

SR инженерүүд дохиоллын байнгын урсгалтай ажилладаг бөгөөд тэдгээрийн ихэнх нь үнэндээ чухал биш юм.

Тиймээс яагаад сэрэмжлүүлэгээ зөвхөн чухал зүйлээр хязгаарлаж болохгүй гэж? Гэсэн хэдий ч энэ аргын тусламжтайгаар та том хохирол учруулахуйц бодит асуудал болж хувирах анхны шинж тэмдгүүдийг танихгүй байж магадгүй юм.

Дуудлагын дагуу ажиллаж буй SRE-ийн үүрэг бол ямар дохиолол нь ноцтой зүйлийг илтгэж байгааг, мөн үүнийг эрчимжүүлж, шийдвэрлэх шаардлагатай эсэхийг тодорхойлох явдал юм. Энэ нь сэрэмжлүүлгийн уян хатан бус байдалтай холбоотой гэж би сэжиглэж байна: дээр дурдсан нөхцөл байдлын дагуу сэрэмжлүүлгийг тохируулах хэд хэдэн түвшний эсвэл "ухаалаг" арга замууд байвал илүү дээр байх болно.

Онцлогын санал: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. Манай жижүүрийн СРЭ-үүд маш их багаж хэрэглэдэг.

Дотоод:

  • GitLab infra төсөл: runbooks энд амьдардаг, ээлж/долоо хоногийн даалгавар, ослын хариу арга хэмжээ.
  • GitLab-тай холбоотой асуудлууд: Мөрдөн байцаалт, хяналт, засвар үйлчилгээг мөн асуудалд хянадаг.
  • GitLab шошго: Автоматжуулалтын даалгавруудыг тусгай шошго ашиглан эхлүүлдэг бөгөөд үүнийг роботууд даалгаврын үйл ажиллагааг хянахад ашигладаг.

Гадна:

  • PagerDuty: Анхааруулга
  • Сул: PagerDuty/AlertManager мессежийн урсгал энд байна. Сэрэмжлүүлэг хаах эсвэл осолд шилжих зэрэг олон төрлийн ажлыг гүйцэтгэхийн тулд ташуу зураастай командуудтай нэгтгэх.
  • Графана: урт хугацааны чиг хандлагад анхаарлаа төвлөрүүлсэн хэмжүүрүүдийн дүрслэл.
  • Кибана: Дүрслэл/лог хайлт, тодорхой үйл явдлуудыг илүү гүнзгий судлах чадварыг өгдөг.
  • Zoom: Zoom-д байнга ажилладаг "breakout room" байдаг. Энэ нь SRE инженерүүдэд үнэ цэнэтэй цагийг дэмий үрэлгүйгээр өрөөг бий болгож, оролцогчдыг холбохгүйгээр үйл явдлуудыг хурдан хэлэлцэх боломжийг олгодог.

Мөн бусад олон.

4. GitLab.com сайтыг GitLab-ээр хянах нь нэг л алдаа юм

Хэрэв GitLab.com үйлчилгээний томоохон саатал гарсан бол энэ нь бидний асуудлыг шийдвэрлэх чадварт нөлөөлөхийг хүсэхгүй байна. GitLab.com-ыг удирдах хоёр дахь GitLab жишээг ажиллуулснаар үүнийг зогсоож болно. Үнэндээ энэ нь бидний хувьд аль хэдийн ажилладаг: https://ops.gitlab.net/.

5. GitLab-д нэмэхэд анхаарах цөөн хэдэн функцууд

  • Олон хэрэглэгчийн даалгавар засварлах, Google Docs-тэй төстэй. Энэ нь үйл явдлын үеэр тохиолдсон ослын талаархи даалгавар, түүнчлэн дүгнэлт хийх ажилд туслах болно. Аль ч тохиолдолд хэд хэдэн оролцогчид бодит цаг хугацаанд ямар нэг зүйл нэмэх шаардлагатай байж магадгүй юм.
  • Даалгавруудад зориулсан илүү олон вэб дэгээ. GitLab-ийн ажлын урсгалын өөр өөр алхмуудыг дотроос нь ажиллуулах чадвар нь таны Slack интеграцчлалаас хамааралтай байдлыг багасгахад тусална. Жишээлбэл, GitLab-ийн асуудалд налуу зураасаар тушаалаар PagerDuty-д анхааруулга өгөх боломж.
    дүгнэлт

SRE-ийн инженерүүд маш их төвөгтэй байдаг. Эдгээр асуудлуудыг шийдвэрлэх GitLab-ийн илүү олон бүтээгдэхүүнийг харах нь сайхан байх болно. Бид дээр дурдсан ажлын явцыг хөнгөвчлөх зарим нэмэлт бүтээгдэхүүн дээр аль хэдийн ажиллаж байна. Дэлгэрэнгүйг хаягаар авах боломжтой Үйл ажиллагааны бүтээгдэхүүний харааны хэсэг.

Бид 2020 онд эдгээр бүх гайхалтай онцлогуудыг нэгтгэхийн тулд багаа өргөжүүлж байна. Сонирхож байвал сонирхоорой сул орон тоо, мөн ямар нэгэн асуулт байвал манай багийн гишүүдтэй холбогдож болно.

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх