Чатын хэлэлцүүлэг дээр үндэслэсэн
Сүүлийн үед DevOps болон SRE-ийн тодорхойлолтын талаар жинхэнэ тулаан өрнөж байна.
Хэдийгээр энэ сэдвийн талаар олон талаар хэлэлцүүлэг өрнүүлсэн ч би тэр дундаа би энэ сэдвээр өөрийн байр сууриа Хабра нийгэмлэгийн шүүхэд хүргэхээр шийдлээ. Сонирхсон хүмүүст муур тавтай морилно уу. Мөн бүх зүйл шинээр эхэлцгээе!
Эрьт урьдын түүх
Тиймээс эрт дээр үед програм хангамж хөгжүүлэгчид болон серверийн администраторуудын баг тусдаа амьдардаг байв. Эхнийх нь кодыг амжилттай бичиж, хоёр дахь нь эхнийх рүү хандсан янз бүрийн халуун дулаан үгсийг ашиглан серверүүдийг суулгаж, хөгжүүлэгчид рүү үе үе ирж, хариуд нь "миний машин дээр бүх зүйл ажилладаг" гэсэн хариултыг хүлээн авдаг. Бизнес нь програм хангамжийг хүлээж байсан, бүх зүйл сул байсан, үе үе эвдэрч, бүгд сандарч байв. Тэр тусмаа энэ бүх замбараагүй байдлыг төлсөн хүн. Гайхамшигт дэнлүүний эрин үе. DevOps хаанаас ирдгийг та аль хэдийн мэдэж байгаа.
DevOps практикийн төрөлт
Дараа нь нухацтай залуус ирээд - энэ бол салбар биш, чи ингэж ажиллаж болохгүй. Мөн тэд амьдралын мөчлөгийн загваруудыг авчирсан. Жишээлбэл, V загвар энд байна.
Тэгэхээр бид юу харж байна вэ? Бизнес нь үзэл баримтлалтай ирдэг, архитекторууд дизайны шийдлүүд, хөгжүүлэгчид код бичдэг, дараа нь бүтэлгүйтдэг. Хэн нэгэн бүтээгдэхүүнийг ямар нэгэн байдлаар туршиж, хэн нэгэн түүнийг эцсийн хэрэглэгчдэд хүргэдэг бөгөөд энэ гайхамшигт загварын гаралтын газар далайн эрэг дээр амласан цаг агаарыг хүлээж ганцаардсан бизнесийн үйлчлүүлэгч сууж байна. Энэ үйл явцыг бий болгоход туслах аргууд хэрэгтэй байна гэсэн дүгнэлтэд хүрсэн. Мөн бид тэдгээрийг хэрэгжүүлэх практикийг бий болгохоор шийдсэн.
Дасгал гэж юу болох тухай уянгын ухралт
Практик гэж би технологи, сахилга батыг хослуулахыг хэлж байна. Жишээ нь terraform кодыг ашиглан дэд бүтцийг дүрслэх практик юм. Сахилга бат бол дэд бүтцийг кодоор хэрхэн дүрслэх, энэ нь хөгжүүлэгчийн толгойд байдаг, технологи нь өөрөө terraform юм.
Мөн тэд тэднийг DevOps практик гэж нэрлэхээр шийдсэн - миний бодлоор тэд Хөгжилөөс Үйл ажиллагаа хүртэл гэсэн үг юм. Бид янз бүрийн ухаалаг зүйлсийг гаргаж ирсэн - CI/CD дадлага, IaC зарчим дээр суурилсан дадлага, мянга мянган. Тэгээд бид явж байна, хөгжүүлэгчид код бичиж, DevOps инженерүүд системийн тайлбарыг код хэлбэрээр ажлын систем болгон хувиргадаг (тиймээ, код нь харамсалтай нь зүгээр л тайлбар боловч системийн биелэл биш), хүргэлт үргэлжилсээр байна. дээр. Өчигдрийн администраторууд шинэ туршлагыг эзэмшиж, DevOps инженерээр бахархалтайгаар дахин сургаж, бүх зүйл урагшилж эхлэв. Тэгээд орой болсон, өглөө байсан... уучлаарай, тэндээс биш.
Бурханд баярлалаа, бүх зүйл дахин сайн биш байна
Бүх зүйл тайвширч, янз бүрийн зальтай "арга зүйчид" DevOps-ын практикийн талаар зузаан ном бичиж эхэлмэгц муу нэртэй DevOps инженер хэн байсан, DevOps бол үйлдвэрлэлийн соёл гэсэн маргаан чимээгүйхэн өрнөв. Гэнэт програм хангамжийг хүргэх нь туйлын энгийн зүйл биш болох нь тодорхой болов. Хөгжлийн дэд бүтэц бүр өөрийн гэсэн стектэй, та үүнийг хаа нэгтээ угсрах хэрэгтэй, хаа нэгтээ хүрээлэн буй орчныг байрлуулах хэрэгтэй, энд танд Tomcat хэрэгтэй, энд үүнийг эхлүүлэх зальтай бөгөөд төвөгтэй арга хэрэгтэй - ерөнхийдөө толгой чинь хүчтэй цохилж байна. Асуудал нь хачирхалтай нь юуны түрүүнд үйл явцыг зохион байгуулахтай холбоотой байв - энэ хүргэх функц нь гацаа шиг үйл явцыг хааж эхлэв. Үүнээс гадна хэн ч Үйл ажиллагааг цуцалсангүй. Энэ нь V-загварт харагдахгүй байгаа ч баруун талд бүхэл бүтэн амьдралын мөчлөг байсаар байна. Үүний үр дүнд ямар нэгэн байдлаар дэд бүтцийг хадгалах, хяналт тавих, зөрчлийг арилгах, хүргэх асуудлыг шийдвэрлэх шаардлагатай байна. Тэдгээр. хөгжил, үйл ажиллагааны аль алинд нь нэг хөлөөрөө сууж, гэнэт Хөгжил ба Үйл ажиллагаа болж хувирав. Тэгээд микро үйлчилгээний талаар ерөнхийдөө шуугиан тарьсан. Мөн тэдэнтэй хамт орон нутгийн машинуудын хөгжүүлэлт үүлэн рүү шилжиж эхлэв - ямар нэг зүйлийг орон нутагт дибаг хийхийг оролдоорой, хэрвээ хэдэн арван, хэдэн зуун микро үйлчилгээ байгаа бол байнгын хүргэлт нь амьд үлдэх хэрэгсэл болдог. "Жижиг даруухан компани"-ын хувьд бүх зүйл зүгээр байсан ч гэсэн? Тэгээд Google?
Google-ийн SRE
Google ирж, хамгийн том какти идэж, шийдсэн - бидэнд энэ хэрэггүй, бидэнд найдвартай байдал хэрэгтэй. Мөн найдвартай байдлыг удирдах ёстой. Бидэнд найдвартай байдлыг удирдан чиглүүлэх мэргэжилтнүүд хэрэгтэй гэж би шийдсэн. Би тэднийг SR инженерүүд гэж дуудаж, энэ нь танд зориулагдсан, үүнийг ердийнх шигээ сайн хий гэж хэлсэн. Энд SLI, энд SLO, энд мониторинг байна. Тэгээд тэр хамраа хагалгаанд оруулав. Мөн тэрээр өөрийн "найдвартай DevOps" SRE гэж нэрлэсэн. Бүх зүйл зүгээр юм шиг байгаа боловч Google-ийн төлж чадах нэг бохир хакерууд байдаг - SR инженерийн албан тушаалд мэргэшсэн хөгжүүлэгч, мөн бага зэрэг гэрийн даалгавар хийж, ажлын системийн ажиллагааг ойлгодог хүмүүсийг ажилд авах. Түүгээр ч барахгүй Google өөрөө ийм хүмүүсийг ажилд авахад асуудалтай байдаг - гол нь энд өөртэйгөө өрсөлддөг тул бизнесийн логикийг хэн нэгэнд тайлбарлах шаардлагатай байдаг. Хүргэлт нь инженерүүдийг суллахаар томилогдсон, SR - инженерүүд найдвартай байдлыг удирддаг (мэдээжийн хэрэг шууд биш, харин дэд бүтцэд нөлөөлөх, архитектурыг өөрчлөх, өөрчлөлт, үзүүлэлтүүдийг хянах, осол аваарыг шийдвэрлэх замаар). Сайхан байна, чи чадна . Хэрэв та Google биш ч найдвартай байдал нь ямар нэгэн байдлаар санаа зовоосон асуудал хэвээр байвал яах вэ?
DevOps санааг хөгжүүлэх
Яг тэр үед lxc-ээс үүссэн Докер ирж, дараа нь Docker Swarm, Kubernetes зэрэг янз бүрийн зохион байгуулалтын системүүд гарч ирэн, DevOps инженерүүд амьсгалаа гаргав - практикийг нэгтгэснээр хүргэх ажлыг хялбаршуулсан. Энэ нь үүнийг маш хялбаршуулсан тул хөгжүүлэгчдэд хүргэх аутсорсинг хийх боломжтой болсон - deployment.yaml гэж юу вэ. Контейнер нь асуудлыг шийддэг. Мөн CI/CD системийн төлөвшил аль хэдийн нэг файл бичих түвшинд хүрээд байгаа бөгөөд үүнийг хөгжүүлэгчид өөрсдөө зохицуулж чадна. Тэгээд дараа нь бид өөрсдийнхөө SRE-ийг хэрхэн хийх талаар ярьж эхэлдэг, ... эсвэл ядаж хэн нэгэнтэй.
SRE нь Google дээр байдаггүй
За, за, бид хүргэлтийг хүргэлээ, бид амьсгалаа гаргаж, админууд нь процессорын ачааллыг ажиглаж, системүүдийг тааруулж, ая тухтай, чимээгүйхэн аяганаас үл ойлгогдох зүйлийг чимээгүйхэн балгаж байсан хуучин сайхан цаг руугаа буцах боломжтой юм шиг байна ... Зогс. Энэ нь бид бүх зүйлийг эхлүүлсэн шалтгаан биш юм (энэ нь харамсалтай!). Гэнэт Google-ийн арга барилд бид маш сайн туршлагыг хялбархан хэрэгжүүлж чаддаг болох нь тодорхой болсон - энэ нь процессорын ачаалал биш, дискээ хэр олон удаа сольж, үүлэн дэх зардлыг оновчтой болгох нь чухал биш, гэхдээ бизнесийн хэмжүүрүүд нь адилхан алдартай юм. SLx. Мөн тэднээс дэд бүтцийн менежментийг хэн ч устгаагүй бөгөөд тэд зөрчлийг арилгах, үе үе жижүүрлэх, ерөнхийдөө бизнесийн үйл явцыг хянах шаардлагатай байна. Залуус аа, бага багаар сайн түвшинд програмчилж эхлээрэй, Google таныг аль хэдийн хүлээж байна.
Нэгтгэн дүгнэхэд. Гэнэт, гэхдээ та аль хэдийн уншихаас залхаж, нийтлэлийн сэтгэгдэл дээр зохиолч руу нулимж, бичихийг тэсэн ядан хүлээж байна. DevOps нь хүргэх практик байсаар ирсэн бөгөөд байх болно. Тэгээд хаашаа ч явахгүй. Үйл ажиллагааны практикийн багц болох SRE нь энэхүү хүргэлтийг амжилттай болгодог.
Эх сурвалж: www.habr.com