Вебинар нь дуу муутай байгаа тул бид үүнийг хуулбарласан.
Намайг Медведев Эдуард гэдэг. Өнөөдөр би SRE гэж юу вэ, SRE хэрхэн гарч ирсэн, SRE инженерүүдийн ажлын шалгуур юу вэ, найдвартай байдлын шалгуурын талаар, түүний хяналтын талаар бага зэрэг ярих болно. Бид орой дээр алхах болно, учир нь та нэг цагийн дотор олон зүйлийг хэлж чадахгүй, гэхдээ би нэмэлт шалгалтын материалыг өгөх болно, бид бүгд таныг хүлээж байна. . XNUMX-р сарын сүүлээр Москвад.
Эхлээд SRE гэж юу болох талаар ярилцъя - Сайтын найдвартай байдлын инженерчлэл. Тэгээд яаж тусдаа байр суурь, тусдаа чиглэл болон гарч ирэв. Уламжлалт хөгжлийн хүрээлэлд Dev болон Ops хоёр тэс өөр баг, ихэвчлэн хоёр тэс өөр зорилготой байдгаас бүх зүйл эхэлсэн. Хөгжлийн багийн зорилго нь шинэ боломжуудыг нэвтрүүлэх, бизнесийн хэрэгцээг хангах явдал юм. Үйл ажиллагааны багийн зорилго бол бүх зүйл ажиллаж, юу ч эвдэрдэггүй эсэхийг шалгах явдал юм. Мэдээжийн хэрэг, эдгээр зорилго нь хоорондоо шууд зөрчилддөг: бүх зүйл ажиллахын тулд, юу ч эвдэхгүй байхын тулд шинэ функцуудыг аль болох бага гарга. Үүнээс болж одоо DevOps гэж нэрлэгддэг аргачлал нь шийдвэрлэх гэж оролдож буй олон дотоод зөрчилдөөнтэй байдаг.
Асуудал нь бидэнд DevOps-ийн тодорхой тодорхойлолт, DevOps-ийн тодорхой хэрэгжилт байхгүй байгаа явдал юм. Би 2 жилийн өмнө Екатеринбургт болсон бага хурал дээр үг хэлж байсан бөгөөд өнөөг хүртэл DevOps хэсэг нь "DevOps гэж юу вэ" гэсэн илтгэлээр эхэлсэн. 2017 онд Devops бараг 10 настай боловч бид энэ нь юу болохыг маргаж байна. Энэ бол Google-ийн хэдэн жилийн өмнө шийдэх гэж оролдсон маш хачирхалтай нөхцөл байдал юм.
2016 онд Google сайтын найдвартай байдлын инженерчлэл нэртэй ном гаргасан. Чухамдаа энэ номоор л SRE хөдөлгөөн эхэлсэн юм. SRE нь тодорхой компанид DevOps парадигмын тодорхой хэрэгжилт юм. SRE инженерүүд нь системийг найдвартай ажиллуулах үүрэг хүлээдэг. Тэдгээр нь ихэвчлэн хөгжүүлэгчдээс, заримдаа хүчирхэг хөгжлийн суурьтай администраторуудаас ирдэг. Тэд системийн администраторуудын хийдэг байсан зүйлийг хийдэг боловч кодын хувьд системийн хөгжил, мэдлэгтэй байх нь эдгээр хүмүүс ердийн удирдлагын ажилд дургүй, харин автоматжуулалтад дуртай болоход хүргэдэг.
SRE багууд дахь DevOps парадигм нь бүтцийн асуудлыг шийддэг SRE инженерүүд байдгаас болж хэрэгждэг нь харагдаж байна. Энэ бол хүмүүсийн 8 жилийн турш ярьж байсан Dev болон Ops хоёрын ижил холболт юм. SRE-ийн үүрэг нь архитектортой адил бөгөөд шинээр ирсэн хүмүүс SRE болдоггүй. Ажил мэргэжлийнхээ эхэнд байгаа хүмүүс хараахан туршлагагүй, шаардлагатай өргөн мэдлэгтэй байдаггүй. Учир нь SRE нь яг юу, хэзээ алдаа гаргаж болох талаар маш нарийн мэдлэг шаарддаг. Тиймээс энд, дүрмээр бол компани дотор болон гадна талд тодорхой туршлага хэрэгтэй.
Тэд SRE болон devops хоёрын ялгааг тайлбарлах эсэхийг асууна. Түүнийг саяхан дүрсэлсэн байна. Байгууллага дахь SRE-ийн байр суурийг бид ярьж болно. Ops нь тусдаа хэлтэс хэвээр байгаа энэхүү сонгодог DevOps арга барилаас ялгаатай нь SRE нь хөгжүүлэлтийн багийн нэг хэсэг юм. Тэд бүтээгдэхүүн боловсруулахад оролцдог. SRE нь нэг хөгжүүлэгчээс нөгөөд шилжих үүрэг гэсэн хандлага хүртэл байдаг. Тэд жишээ нь UX дизайнерууд, хөгжүүлэгчид өөрсдөө, заримдаа бүтээгдэхүүний менежерүүдтэй ижил аргаар кодын үнэлгээнд оролцдог. SRE нь ижил түвшинд ажилладаг. Бид тэдгээрийг батлах хэрэгтэй, бид тэдгээрийг хянаж үзэх хэрэгтэй, ингэснээр байршуулалт бүрт SRE нь: "За, энэ байршуулалт, энэ бүтээгдэхүүн найдвартай байдалд сөргөөр нөлөөлөхгүй. Хэрэв тийм бол зарим зөвшөөрөгдөх хязгаарт багтана. Энэ талаар бид бас ярих болно.
Үүний дагуу SRE кодыг өөрчлөхөд хориг тавих эрхтэй. Ерөнхийдөө энэ нь SRE-ийг буруу хэрэгжүүлбэл зарим төрлийн жижиг зөрчилдөөнд хүргэдэг. Сайтын найдвартай байдлын инженерчлэлийн тухай ижил номонд эдгээр зөрчилдөөнөөс хэрхэн зайлсхийх талаар нэг ч биш олон хэсэг өгүүлдэг.
Тэд SRE нь мэдээллийн аюулгүй байдалтай хэрхэн холбогдож байгааг асуудаг. SRE нь мэдээллийн аюулгүй байдалд шууд оролцдоггүй. Үндсэндээ томоохон компаниудад үүнийг хувь хүмүүс, тестер, шинжээчид хийдэг. Гэхдээ SRE нь аюулгүй байдалд нөлөөлдөг зарим үйл ажиллагаа, зарим үүрэг даалгавар, байршуулалт нь бүтээгдэхүүний хүртээмжид нөлөөлдөг гэсэн утгаараа тэдэнтэй харилцдаг. Тиймээс SRE нь бүхэлдээ ямар ч баг, тэр дундаа аюулгүй байдлын баг, тэр дундаа шинжээчидтэй харилцдаг. Тиймээс, DevOps-ийг хэрэгжүүлэх гэж оролдох үед SRE нь голчлон хэрэгтэй байдаг ч хөгжүүлэгчдийн ачаалал хэтэрхий том болдог. Өөрөөр хэлбэл, хөгжлийн баг нь одоо тэд бас Ops-ийг хариуцах шаардлагатай байгааг даван туулж чадахгүй. Мөн тусдаа үүрэг байдаг. Энэ үүргийг төсөвт тусгасан. Заримдаа энэ үүрэг нь багийн хэмжээгээр тодорхойлогддог, тусдаа хүн гарч ирдэг, заримдаа хөгжүүлэгчдийн нэг нь болдог. Анхны SRE багт ийм байдлаар гарч ирдэг.
SRE-д өртөж буй системийн нарийн төвөгтэй байдал, үйл ажиллагааны найдвартай байдалд нөлөөлдөг нарийн төвөгтэй байдал нь зайлшгүй бөгөөд санамсаргүй юм. Шаардлагатай нарийн төвөгтэй байдал нь бүтээгдэхүүний нарийн төвөгтэй байдал нь шинэ бүтээгдэхүүний шинж чанарт шаардагдах хэмжээгээр нэмэгдэхийг хэлнэ. Санамсаргүй төвөгтэй байдал гэдэг нь системийн нарийн төвөгтэй байдал нэмэгдэх боловч бүтээгдэхүүний онцлог, бизнесийн шаардлага нь үүнд шууд нөлөөлдөггүй. Хөгжүүлэгч хаа нэгтээ алдаа гаргасан, эсвэл алгоритм нь оновчтой биш эсвэл тусгай хэрэгцээ шаардлагагүйгээр бүтээгдэхүүний нарийн төвөгтэй байдлыг нэмэгдүүлдэг нэмэлт ашиг сонирхлыг нэвтрүүлсэн нь харагдаж байна. Сайн SRE нь энэ байдлыг үргэлж таслах ёстой. Өөрөөр хэлбэл, санамсаргүй нэмэлтээс болж хүндрэл нэмэгддэг аливаа үүрэг даалгавар, байршуулалт, татах хүсэлтийг хаах хэрэгтэй.
Яагаад зүгээр нэг инженер, системийн администраторыг багтаа асар их мэдлэгтэй ажиллуулж болохгүй гэж. Инженерийн дүрд байгаа хөгжүүлэгч нь боловсон хүчний хамгийн сайн шийдэл биш гэж бидэнд хэлдэг. Инженерийн дүрд тоглодог хөгжүүлэгч нь боловсон хүчний хамгийн сайн шийдэл байдаггүй, гэхдээ энд гол зүйл бол Ops чиглэлээр ажилладаг хөгжүүлэгч нь автоматжуулалтыг бага зэрэг илүү хүсдэг, бага зэрэг илүү мэдлэг, ур чадвар эзэмшсэн байдаг. энэ автоматжуулалт. Үүний дагуу бид зөвхөн зарим тодорхой үйлдлүүдийн цагийг төдийгүй ердийн горимыг төдийгүй MTTR (Сэргээх дундаж хугацаа, нөхөн сэргээх хугацаа) зэрэг бизнесийн чухал параметрүүдийг багасгадаг. Тиймээс бид энэ талаар бага зэрэг дараа ярих болно, бид байгууллагад мөнгө хэмнэдэг.
Одоо SRE-ийн үйл ажиллагааны шалгуурын талаар ярилцъя. Юуны өмнө найдвартай байдлын талаар. Жижиг компаниуд, стартап компаниудад хүмүүс үйлчилгээгээ сайн бичвэл, бүтээгдэхүүнээ зөв, зөв бичвэл ажиллана, хагарахгүй гэж төсөөлөх нь олонтаа. Ингээд л бид сайн код бичдэг болохоор эвдэх зүйл байхгүй. Код нь маш энгийн, эвдэх зүйл байхгүй. Эдгээр нь бидэнд шалгалт хэрэггүй гэж хэлдэг хүмүүсийн тухай юм, учир нь эдгээр нь VPI гурван арга юм, яагаад энд эвдэрсэн юм бэ.
Энэ бүхэн мэдээж буруу. Эдгээр хүмүүс практик дээр ийм кодыг ихэвчлэн хаздаг, учир нь бүх зүйл эвдэрдэг. Аливаа зүйл заримдаа хамгийн таамаглашгүй байдлаар эвдэрдэг. Заримдаа хүмүүс үгүй, хэзээ ч болохгүй гэж хэлдэг. Мөн энэ нь үргэлж тохиолддог. Энэ нь хангалттай олон удаа тохиолддог. Тийм ч учраас хэн ч 100% хүртээмжтэй байхыг хичээдэггүй, учир нь 100% хүртээмж хэзээ ч тохиолддоггүй. Энэ бол норм юм. Тиймээс бид үйлчилгээний хүртээмжийн талаар ярихдаа есөн тухай ярьдаг. 2 ес, 3 ес, 4 ес, 5 ес. Хэрэв бид үүнийг сул зогсолт гэж орчуулбал, жишээлбэл, 5 ес, энэ нь жилд 5 минутаас арай илүү зогсолт, 2 ес нь 3,5 хоногийн сул зогсолт юм.
Гэхдээ хэзээ нэгэн цагт POI, хөрөнгө оруулалтын өгөөж буурч байгаа нь ойлгомжтой. Хоёр есөөс гурван ес хүртэл явна гэдэг 3-аас дээш хоногоор сул зогсолтыг бууруулна гэсэн үг. Дөрвөн есөөс тав хүртэл явах нь сул зогсолтыг жилд 47 минутаар бууруулдаг. Бизнесийн хувьд энэ нь тийм ч чухал биш байж магадгүй юм. Тэгээд ерөнхийдөө шаардлагатай найдвартай байдал нь техникийн асуудал биш, нэгдүгээрт, энэ бол бизнесийн асуудал, энэ бол бүтээгдэхүүний асуудал юм. Бүтээгдэхүүний хэрэглэгчдэд ямар түвшний сул зогсолтыг хүлээн зөвшөөрөх боломжтой, тэд юу хүлээж байгаа, тэд хэр их мөнгө төлдөг, жишээлбэл, хэр их мөнгө алддаг, систем хэр их мөнгө алддаг.
Энд байгаа чухал асуулт бол үлдсэн бүрэлдэхүүн хэсгүүдийн найдвартай байдал гэж юу вэ. Учир нь 4 ес найдвартай ухаалаг утсанд 5 ба 2 есийн ялгаа харагдахгүй. Товчхондоо, хэрэв таны үйлчилгээнд байгаа ухаалаг гар утсанд жилд 10 удаа ямар нэгэн зүйл эвдэрч байвал үйлдлийн системд 8 удаа эвдэрсэн байх магадлалтай. Хэрэглэгч үүнд дассан бөгөөд жилд нэг удаа анхаарал хандуулахгүй. Найдвартай байдлыг нэмэгдүүлэх, ашгийг нэмэгдүүлэх үнийг уялдуулах шаардлагатай байна.
Зүгээр л SRE-ийн тухай номонд 4 ес байсныг 3 ес болгож өсгөсөн сайн жишээ бий. Эндээс харахад хүртээмжийн өсөлт 0,1% -иас бага байна. Үйлчилгээний орлого жилдээ 1 сая доллар бол орлогын өсөлт нь 900 доллар болно. Боломжийг есөөр нэмэгдүүлэхийн тулд жилд 900 доллараас бага зардал гарах юм бол энэ өсөлт нь санхүүгийн ач холбогдолтой юм. Хэрэв энэ нь жилд 900 доллараас илүү үнэтэй бол энэ нь утгагүй болно, учир нь орлогын өсөлт нь хөдөлмөрийн зардал, нөөцийн зардлыг нөхөж чадахгүй. Мөн 3 ес бидэнд хангалттай байх болно.
Энэ нь мэдээжийн хэрэг, бүх хүсэлт тэнцүү байх хялбаршуулсан жишээ юм. Мөн 3 есөөс 4 ес хүртэл явах нь хангалттай хялбар, гэхдээ жишээлбэл, 2 есөөс 3 хүртэл явах нь аль хэдийн 9 мянган долларын хэмнэлт юм, энэ нь санхүүгийн хувьд утга учиртай юм. Мэдээжийн хэрэг, бодит байдал дээр бүртгэлийн хүсэлтийн бүтэлгүйтэл нь хуудсыг харуулахгүй байхаас ч дор юм, хүсэлтүүд өөр өөр жинтэй байдаг. Тэд бизнесийн үүднээс огт өөр шалгууртай байж болох ч, дүрмээр бол, хэрэв бид тодорхой үйлчилгээний талаар ярихгүй бол энэ нь нэлээд найдвартай ойролцоо байна.
Үйлчилгээний архитектурын шийдлийг сонгохдоо SRE нь зохицуулагчдын нэг мөн үү гэсэн асуулт бидэнд ирсэн. Тогтвортой байдал нь алдагдахгүйн тулд одоо байгаа дэд бүтцээ нэгтгэх талаас нь хэлье. Тийм ээ, SRE нь хүсэлтийг татах, гүйцэтгэх, гаргах зэрэг нь архитектур, шинэ үйлчилгээ, бичил үйлчилгээ нэвтрүүлэх, шинэ шийдлүүдийг хэрэгжүүлэхэд нөлөөлдөг. Туршлага хэрэгтэй, мэргэшил хэрэгтэй гэж би яагаад өмнө нь хэлсэн юм. Үнэн хэрэгтээ SRE бол ямар ч архитектур, програм хангамжийн шийдэлд саад болох дуу хоолойнуудын нэг юм. Үүний дагуу инженерийн хувьд SRE нь юуны өмнө зөвхөн ойлгохоос гадна зарим тодорхой шийдвэр нь найдвартай байдал, тогтвортой байдалд хэрхэн нөлөөлөхийг ойлгох ёстой бөгөөд энэ нь бизнесийн хэрэгцээтэй хэрхэн холбоотой, ямар өнцгөөс хүлээн зөвшөөрөгдөж болохыг ойлгох ёстой. аль нь биш.
Тиймээс одоо бид SRE-д SLA (Үйлчилгээний түвшний гэрээ) гэж уламжлалт байдлаар тодорхойлсон найдвартай байдлын шалгууруудын талаар ярьж болно. Магадгүй танил нэр томъёо. SLI (Үйлчилгээний түвшний үзүүлэлт). SLO (Үйлчилгээний түвшний зорилго). Үйлчилгээний түвшний гэрээ гэдэг нь ялангуяа сүлжээ, үйлчилгээ үзүүлэгч, хостингтой ажиллаж байсан бол бэлгэдлийн нэр томъёо байж магадгүй юм. Энэ бол таны үйлчилгээний бүх гүйцэтгэл, торгууль, алдааны зарим торгууль, хэмжигдэхүүн, шалгуур үзүүлэлтүүдийг тодорхойлсон ерөнхий гэрээ юм. Мөн SLI бол бэлэн байдлын хэмжүүр юм. Өөрөөр хэлбэл, SLI гэж юу байж болох вэ: үйлчилгээнээс хариу өгөх хугацаа, алдааны тоо хувь. Хэрэв энэ нь ямар нэгэн төрлийн файл байршуулах юм бол энэ нь зурвасын өргөн байж болно. Алгоритмыг таних тухайд индикатор нь жишээлбэл хариултын зөв байдал ч байж болно. SLO (Үйлчилгээний түвшний зорилго) нь SLI үзүүлэлт, түүний утга, хугацааны хослол юм.
SLA ийм байж болно гэж бодъё. Үйлчилгээг жилийн турш 99,95% ашиглах боломжтой. Эсвэл 99 чухал дэмжлэг үзүүлэх тасалбарыг улиралд 3 цагийн дотор хаах болно. Эсвэл хүсэлтийн 85% нь сар бүр 1,5 секундын дотор хариулах болно. Өөрөөр хэлбэл, бид алдаа, бүтэлгүйтэл нь хэвийн зүйл гэдгийг аажмаар ойлгодог. Энэ бол хүлээн зөвшөөрч болохуйц нөхцөл байдал, бид үүнийг төлөвлөж байгаа, бүр тодорхой хэмжээгээр найдаж байна. Өөрөөр хэлбэл, SRE нь алдаа гаргах боломжтой системийг бий болгодог бөгөөд энэ нь алдааг харгалзан үзэх ёстой. Боломжтой бол тэд алдааг хэрэглэгч анзаарахгүй, анзаарахгүй байхаар зохицуулах ёстой, гэхдээ ямар нэгэн байдлаар шийдвэрлэх арга зам байгаа бөгөөд үүний ачаар бүх зүйл бүрэн унахгүй.
Жишээлбэл, хэрэв та YouTube-д видео байршуулж, YouTube үүнийг шууд хөрвүүлэх боломжгүй, хэрэв видео хэтэрхий том, формат нь оновчтой биш бол хүсэлт нь мэдээжийн хэрэг завсарлага авахгүй, YouTube 502 алдаа өгөхгүй. , YouTube: "Бид бүгдийг бүтээсэн, таны видеог боловсруулж байна. 10 минутын дараа бэлэн болно." Энэ бол дэгжин доройтлын зарчим бөгөөд жишээлбэл, хэрэв та үүнийг хийж байсан бол урд талын хөгжүүлэлтээс эхлээд мэддэг.
Найдвартай, алдаатай, хүлээлттэй ажиллахад маш чухал ач холбогдолтой бидний ярих дараагийн нэр томъёо бол MTBF ба MTTR юм. MTBF нь бүтэлгүйтлийн хоорондох дундаж хугацаа юм. MTTR Сэргээх дундаж хугацаа, нөхөн сэргээх дундаж хугацаа. Өөрөөр хэлбэл, алдаа илэрсэн мөчөөс эхлээд алдаа гарч ирснээс хойш үйлчилгээг бүрэн хэвийн ажиллагаанд оруулах хүртэл хэр их хугацаа өнгөрсөн байна. MTBF нь голчлон кодын чанар дээр ажилласнаар тогтоогддог. Энэ нь SRE нь "үгүй" гэж хэлж чадна гэсэн үг юм. Мөн та SRE "үгүй" гэж хэлэхэд тэр үүнийг хор хөнөөлтэй учраас биш, муу учраас биш, тэгэхгүй бол хүн бүр зовох болно гэдгийг та бүхэл бүтэн баг ойлгох хэрэгтэй.
Дахин хэлэхэд, бусад хөгжүүлэгчид SRE-ийг үзэн ядаж эхлэхгүй байх талаар миний байнга дурддаг номонд ч гэсэн маш олон нийтлэл, маш олон арга, олон арга зам байдаг. Нөгөө талаас MTTR нь таны SLO (Үйлчилгээний түвшний зорилго) дээр ажиллах тухай юм. Мөн энэ нь ихэвчлэн автоматжуулалт юм. Учир нь, жишээ нь, манай SLO нь улиралд 4 есөн ажиллах хугацаа юм. Энэ нь 3 сарын хугацаанд бид 13 минутын завсарлага авах боломжтой гэсэн үг юм. MTTR нь 13 минутаас хэтрэхгүй байх болно. Хэрэв бид 13 минутын дотор дор хаяж 1 удаа зогсолтод хариу өгөх юм бол энэ нь улирлын төсвийг бүхэлд нь дуусгасан гэсэн үг юм. Бид SLO-г эвдэж байна. Гэмтлийг арилгах, хариу үйлдэл үзүүлэхэд 13 минут зарцуулдаг бол машины хувьд маш их хугацаа, харин хүний хувьд маш богино хугацаа юм. Учир нь хүн сэрэмжлүүлэг хүлээн авах хүртэл, хариу үйлдэл үзүүлэх хүртэл, алдаагаа ойлгох хүртэл аль хэдийн хэдэн минут болно. Хүн үүнийг яаж засах, яг юу засах, юу хийхээ ойлгох хүртэл хэдэн минут болно. Үнэн хэрэгтээ та серверээ дахин эхлүүлэх эсвэл шинэ зангилаа босгох шаардлагатай байсан ч гараар MTTR нь 7-8 минут болно. Процессыг автоматжуулах үед MTTR нь ихэвчлэн секунд, заримдаа миллисекундэд хүрдэг. Google ихэвчлэн миллисекундын тухай ярьдаг ч бодит байдал дээр мэдээж бүх зүйл тийм ч сайн биш юм.
Хамгийн тохиромжтой нь SRE нь ажлаа бараг бүрэн автоматжуулах ёстой, учир нь энэ нь MTTR, түүний хэмжүүр, бүх үйлчилгээний SLO, үүний дагуу бизнесийн ашигт шууд нөлөөлдөг. Хэрэв хугацаа хэтэрсэн бол бид SRE буруутай эсэхийг асууна. Аз болоход хэн ч буруугүй. Мөн энэ бол гашуун үхлийн дараа гэж нэрлэгддэг тусдаа соёл бөгөөд бид өнөөдөр ярихгүй, гэхдээ бид үүнийг Slurm дээр шинжлэх болно. Энэ бол маш их ярьж болох маш сонирхолтой сэдэв юм. Бүдүүлэгээр хэлэхэд улирал тутамд заасан хугацаа хэтэрсэн тохиолдолд хүн бүр бага зэрэг буруутай, энэ нь хүн бүрийг буруутгах нь бүтээмжгүй гэсэн үг юм, үүний оронд магадгүй хэн нэгнийг буруутгахгүй, харин нөхцөл байдлыг засч, өөрт байгаа зүйлээрээ ажиллацгаая. Миний туршлагаас харахад энэ арга нь ихэнх багуудад, ялангуяа Орост бага зэрэг харь, гэхдээ энэ нь утга учиртай бөгөөд маш сайн ажилладаг. Тиймээс, би нийтлэл, уран зохиолын төгсгөлд энэ сэдвээр уншихыг зөвлөж байна. Эсвэл Slurm SRE-д ирээрэй.
Би тайлбарлая. Хэрэв улирал тутамд SLO-ийн хугацаа хэтэрсэн бол сул зогсолт 13 минут биш харин 15 минут байсан бол үүнд хэн буруутай вэ? Мэдээжийн хэрэг, SRE буруутай байж магадгүй, учир нь тэр ямар нэгэн муу үйлдэл эсвэл байршуулалт хийсэн нь тодорхой. Дата төвийн администратор үүнд буруутай байж магадгүй, учир нь тэр ямар нэгэн төлөвлөгөөт бус засвар үйлчилгээ хийсэн байж магадгүй юм. Хэрэв мэдээллийн төвийн администратор үүнд буруутай бол SLO-г зохицуулахдаа засвар үйлчилгээ тооцоогүй Ops-ийн хүн буруутай. Дата төвийн гэрээнд гарын үсэг зурсан менежер, техникийн захирал эсвэл дата төвийн SLA нь шаардлагатай сул зогсолтод зориулагдаагүй байгааг анхаарч үзээгүй хүн үүнд буруутай. Үүний дагуу энэ нөхцөл байдалд бүгд бага багаар буруутгах болно. Тэгээд ч ийм нөхцөлд хэн нэгэнд бурууг тохох нь утгагүй гэсэн үг. Гэхдээ мэдээж үүнийг засах хэрэгтэй. Тиймээс үхлийн дараах шинжилгээ байдаг. Хэрэв та жишээ нь, GitHub-ийн үхлийн дараах нийтлэлийг уншсан бөгөөд энэ нь тодорхой тохиолдол бүрт маш сонирхолтой, жижиг, гэнэтийн түүх байдаг бол хэн ч энэ хүнийг буруутай гэж хэлээгүй гэдгийг орлуулж болно. Бурууг үргэлж тодорхой төгс бус үйл явц дээр тавьдаг.
Дараагийн асуулт руугаа орцгооё. Автоматжуулалт. Би автоматжуулалтын талаар бусад нөхцөл байдалд ярихдаа, хэмнэж байгаагаас илүү их цаг зарцуулалгүйгээр даалгаврыг автоматжуулахын тулд хэр удаан ажиллах боломжтойг харуулсан хүснэгтийг ихэвчлэн ашигладаг. Гадаа байна. Хамгийн гол нь SRE нь даалгаврыг автоматжуулах үед автоматжуулалт нь MTTR-д шууд нөлөөлдөг тул цаг хэмнээд зогсохгүй мөнгө хэмнэдэг. Тэд ажилчид болон хөгжүүлэгчдийн сэтгэл санааг хэмнэдэг бөгөөд энэ нь бас шавхагдашгүй нөөц юм. Тэд ердийн горимыг багасгадаг. Автоматжуулалт нь цаг хугацааны зардлын хувьд утгагүй мэт санагдаж байсан ч энэ бүхэн ажил, үр дүнд нь бизнест эерэг нөлөө үзүүлдэг.
Үнэн хэрэгтээ энэ нь бараг үргэлж байдаг бөгөөд SRE-ийн дүрд ямар нэг зүйлийг автоматжуулах ёсгүй тохиолдол маш цөөхөн байдаг. Дараа нь бид алдааны төсөв, алдааны төсөв гэж нэрлэгддэг зүйлийн талаар ярих болно. Үнэн хэрэгтээ, хэрэв бүх зүйл таны өөртөө тавьсан SLO-ээс хамаагүй дээр байвал энэ нь тийм ч сайн биш юм. Энэ нь маш муу, учир нь SLO нь зөвхөн доод хязгаар төдийгүй ойролцоогоор дээд хязгаар болж ажилладаг. Та өөртөө SLO-г 99% -ийн хүртээмжтэй болгож, үнэн хэрэгтээ танд 99,99% байгаа бол бизнест огт хор хөнөөл учруулахгүй туршилт хийх зай байгаа нь харагдаж байна, учир нь та өөрөө энэ бүгдийг хамтдаа тодорхойлсон бөгөөд та энэ зайг ашиглахгүй. Танд алдаа гаргах төсөв байгаа бөгөөд таны хувьд үүнийг зарцуулдаггүй.
Үүнийг бид яах вэ. Бид үүнийг бүх зүйлд ашигладаг. Үйлдвэрлэлийн нөхцөлд туршилт хийх, гүйцэтгэлд нөлөөлж болзошгүй шинэ функцуудыг нэвтрүүлэх, хувилбаруудыг гаргах, засвар үйлчилгээ хийх, төлөвлөсөн зогсолтуудад зориулагдсан. Урвуу дүрэм мөн хамаарна: хэрэв төсөв дууссан бол бид шинэ зүйл гаргаж чадахгүй, эс тэгвээс бид SLO-г давах болно. Төсөв аль хэдийн дууссан, гүйцэтгэлд сөргөөр нөлөөлсөн, өөрөөр хэлбэл энэ нь өөрөө SLO-г шууд өсгөдөг ямар нэгэн засвар биш бол бид төсвөөс хэтрээд байна, энэ нь муу нөхцөл байдал юм. , үүнд дүн шинжилгээ хийх, нас барсны дараа, магадгүй зарим үйл явцыг засах шаардлагатай.
Өөрөөр хэлбэл, хэрэв үйлчилгээ нь өөрөө сайн ажиллахгүй, SLO зарцуулж, төсвийг туршилтанд биш, зарим хувилбаруудад биш, харин өөрөө зарцуулдаг бол сонирхолтой функцүүдийн оронд зарим сонирхолтой засваруудын оронд, сонирхолтой хувилбаруудын оронд. Аливаа бүтээлч ажлын оронд та төсвөө цэгцлэх, эсвэл SLO-г засварлахын тулд тэнэг засвар хийх хэрэгтэй болно, энэ нь бас тийм ч олон тохиолдох ёсгүй үйл явц юм.
Тиймээс бид алдаа гаргахад илүү төсөвтэй байгаа нөхцөлд SRE болон хөгжүүлэгчид бүгд сонирхож байгаа нь харагдаж байна. Хөгжүүлэгчдийн хувьд алдааны том төсөв нь та хувилбар, туршилт, туршилтыг шийдвэрлэх боломжтой гэсэн үг юм. SRE-ийн хувьд алдааны төсөв, тэр төсөвт оруулна гэдэг нь шууд ажлаа сайн хийж байна гэсэн үг. Энэ нь зарим төрлийн хамтарсан ажлын сэдэлд нөлөөлдөг. Хэрэв та SRE-ээ хөгжүүлэгчийн хувьд сонсвол сайн ажил хийх орон зай ихтэй, ердийн зүйл багатай байх болно.
Үйлдвэрлэлийн туршилтууд нь томоохон багуудад SRE-ийн нэлээд чухал бөгөөд бараг салшгүй хэсэг болох нь харагдаж байна. Үүнийг ихэвчлэн Chaos Monkey хэмээх хэрэгслийг гаргасан Netflix-ийн багаас гаралтай эмх замбараагүй инженерчлэл гэж нэрлэдэг.
Chaos Monkey нь CI/CD дамжуулах хоолойд холбогдож, үйлдвэрлэлийн явцад серверийг санамсаргүйгээр сүйрүүлдэг. Дахин хэлэхэд, SRE бүтцэд бид уналтад орсон сервер нь өөрөө муу биш, хүлээгдэж буй тухай ярьж байна. Тэгээд төсөвт багтсан бол хүлээн зөвшөөрч болохуйц, бизнест хохирол учруулахгүй. Мэдээжийн хэрэг, Netflix хангалттай нэмэлт серверүүдтэй, хангалттай хуулбартай тул энэ бүгдийг засах боломжтой бөгөөд хэрэглэгч бүхэлдээ анзаарахгүй, бүр хэн ч ямар ч төсөвт нэг сервер үлдээдэггүй.
Netflix-д хэсэг хугацаанд ийм хэрэгслүүдийн бүхэл бүтэн багц байсан бөгөөд тэдгээрийн нэг болох Chaos Gorilla нь Амазоны боломжтой бүсүүдийн нэгийг бүрмөсөн хаадаг. Ийм зүйл нь юунд нөлөөлж, юунаас хамаарах нь бүрэн тодорхойгүй үед, нэгдүгээрт, далд хамаарлыг илрүүлэхэд тусалдаг. Хэрэв та бичил үйлчилгээтэй ажиллаж байгаа бөгөөд баримт бичиг нь тийм ч төгс биш бол энэ нь танд танил байж магадгүй юм. Дахин хэлэхэд, энэ нь тайзан дээр барьж авах боломжгүй кодын алдааг олж авахад маш их тусалдаг, учир нь ямар ч шатлалт нь яг загварчлал биш, учир нь ачааллын хэмжээ өөр, ачааллын загвар өөр, тоног төхөөрөмж бас, хамгийн их магадлалтай, бусад. Оргил ачаалал нь гэнэтийн, урьдчилан таамаглах аргагүй байж болно. Төсвөөс давж гарахгүй ийм туршилт нь дэд бүтцийн алдаа, автомат туршилт, CI / CD дамжуулах хоолойд хэзээ ч барьж чадахгүй алдааг олж авахад тусалдаг. Энэ бүхэн таны төсөвт багтсан л бол таны үйлчилгээ доошилсон нь хамаагүй, гэхдээ энэ нь маш аймшигтай мэт санагдаж байсан ч сервер унтарсан, ямар хар дарсан зүүд вэ. Үгүй ээ, энэ бол хэвийн зүйл, энэ нь сайн, энэ нь алдаануудыг барихад тусалдаг. Хэрэв танд төсөв байгаа бол түүнийгээ зарцуулж болно.
А: Би ямар уран зохиол санал болгож чадах вэ? Төгсгөлд нь жагсаана уу. Уран зохиол маш их байгаа, би хэдэн илтгэл зөвлөх болно. Энэ нь хэрхэн ажилладаг вэ, SRE нь өөрийн програм хангамжийн бүтээгдэхүүнгүй эсвэл хамгийн бага хөгжүүлэлттэй компаниудад ажилладаг. Жишээлбэл, үндсэн үйл ажиллагаа нь програм хангамж биш аж ахуйн нэгжид. Үндсэн үйл ажиллагаа нь програм хангамж биш аж ахуйн нэгжид SRE нь бусад газартай яг адилхан ажилладаг, учир нь аж ахуйн нэгжид та бас хөгжөөгүй байсан ч гэсэн програм хангамжийн бүтээгдэхүүн ашиглах хэрэгтэй, шинэчлэлтүүдийг гаргах хэрэгтэй, та өөрчлөх хэрэгтэй. дэд бүтэц, та өсөх хэрэгтэй, та масштабтай байх хэрэгтэй. Мөн SRE нь эдгээр үйл явцад гарч болзошгүй асуудлуудыг тодорхойлж, урьдчилан таамаглахад тусалдаг бөгөөд зарим өсөлт эхэлж, бизнесийн хэрэгцээ өөрчлөгдсөний дараа тэдгээрийг хянах боломжтой. Учир нь хэрэв та дор хаяж хэд хэдэн сервертэй бол SRE-тэй байхын тулд програм хангамж боловсруулахад оролцох шаардлагагүй бөгөөд наад зах нь бага зэрэг өсөлттэй байх болно.
Жижиг төслүүд, жижиг байгууллагууд ч мөн адил, учир нь том компаниудад туршилт хийх төсөв, орон зай байдаг. Гэхдээ үүнтэй зэрэгцэн туршилтын эдгээр бүх үр жимсийг хаана ч ашиглаж болно, өөрөөр хэлбэл SRE нь мэдээж Google, Netflix, Dropbox дээр гарч ирсэн. Гэхдээ үүнтэй зэрэгцэн жижиг компаниуд болон стартапууд хураангуй материалыг уншиж, ном уншиж, тайлан үзэх боломжтой. Тэд энэ талаар илүү олон удаа сонсож эхэлдэг, тэд тодорхой жишээнүүдийг хардаг, миний бодлоор энэ нь зүгээр юм, энэ нь үнэхээр хэрэгтэй байж болох юм, энэ нь бидэнд ч хэрэгтэй, гайхалтай юм.
Энэ нь эдгээр үйл явцыг стандартчилах бүх үндсэн ажлыг аль хэдийн танд зориулж хийсэн болно. Танай компанид SRE-ийн гүйцэтгэх үүргийг тусгайлан тодорхойлж, дахин тайлбарласан эдгээр бүх туршлагыг бодитоор хэрэгжүүлж эхлэх нь танд үлдэх болно. Өөрөөр хэлбэл, жижиг компаниудад хэрэгтэй зарчмуудаас харахад энэ нь үргэлж SLA, SLI, SLO гэсэн тодорхойлолт юм. Хэрэв та програм хангамжид оролцдоггүй бол эдгээр нь дотоод SLA болон дотоод SLO, алдааны дотоод төсөв болно. Энэ нь бараг үргэлж баг болон бизнесийн хүрээнд сонирхолтой хэлэлцүүлгүүдэд хүргэдэг, учир нь та дэд бүтэц, хамгийн тохиромжтой үйл явцын зохион байгуулалтад зарцуулж болох тул хамгийн тохиромжтой шугам хоолой нь шаардлагатай хэмжээнээс хамаагүй их юм. Мэдээллийн технологийн хэлтэст байгаа эдгээр 4 ес нь танд одоо хэрэггүй болно. Гэхдээ үүнтэй зэрэгцэн та цагаа зарцуулж, төсвөө өөр зүйлд зарцуулж болно.
Үүний дагуу хяналт, мониторингийн зохион байгуулалт нь ямар ч хэмжээтэй компанид ашигтай байдаг. Ерөнхийдөө ийм сэтгэлгээ, алдаа нь хүлээн зөвшөөрөгдөхүйц зүйл, төсөвтэй, хаана зорилт байна, энэ нь 3 хүний стартапаас эхлээд ямар ч хэмжээний компанид ашигтай байдаг.
Хамгийн сүүлд ярих ёстой техникийн нюанс бол хяналт юм. Учир нь хэрэв бид SLA, SLI, SLO-ийн тухай ярьж байгаа бол бид төсөвт нийцэж байгаа эсэх, Зорилгодоо нийцэж байгаа эсэх, эцсийн SLA-д хэрхэн нөлөөлж байгааг хянахгүйгээр ойлгох боломжгүй юм. Хяналт нь иймэрхүү болдог гэдгийг би маш олон удаа харсан: сервер рүү илгээсэн хүсэлтийн хугацаа, дундаж хугацаа эсвэл мэдээллийн санд ирсэн хүсэлтийн тоо гэх мэт тодорхой утга байдаг. Түүнд инженерийн тогтоосон стандарт бий. Хэрэв хэмжигдэхүүн нь нормоос зөрүүтэй байвал и-мэйл ирнэ. Дүрмээр бол энэ нь огт хэрэггүй зүйл юм, учир нь энэ нь сэрэмжлүүлэг, хяналтаас ирсэн мессежийн бөөгнөрөл рүү хөтөлдөг тул хүн эхлээд тэдгээрийг бүртгэх ёстой, өөрөөр хэлбэл хэмжүүрийн утгыг тодорхойлох ёстой. ямар нэг арга хэмжээ авах хэрэгцээ. Хоёрдугаарт, түүнээс ямар ч арга хэмжээ авах шаардлагагүй үед тэр эдгээр бүх сэрэмжлүүлгийг анзаарахаа больдог. Энэ бол сайн хяналтын дүрэм бөгөөд SRE-ийг хэрэгжүүлэх хамгийн эхний дүрэм бол зөвхөн арга хэмжээ авах шаардлагатай үед мэдэгдэл ирэх ёстой.
Стандарт тохиолдолд үйл явдлын 3 түвшин байдаг. Сэрэмжлүүлэг байна, тасалбар байна, бүртгэл байна. Анхааруулга нь яаралтай арга хэмжээ авахыг шаарддаг бүх зүйл юм. Энэ нь бүх зүйл эвдэрсэн тул та яг одоо засах хэрэгтэй. Тасалбар бол хойшлуулсан арга хэмжээ шаарддаг. Тиймээ, та ямар нэг зүйл хийх хэрэгтэй, гараар ямар нэг зүйл хийх хэрэгтэй, автоматжуулалт амжилтгүй болсон, гэхдээ дараагийн хэдэн минутын турш үүнийг хийх шаардлагагүй. Бүртгэл нь ямар ч арга хэмжээ авах шаардлагагүй бөгөөд ерөнхийдөө бүх зүйл сайн байвал хэн ч уншихгүй. Эргээд харахад хэсэг хугацаанд ямар нэг зүйл эвдэрсэн, бид энэ талаар мэдээгүй байх үед л та бүртгэлийг унших хэрэгтэй болно. Эсвэл судалгаа хийх хэрэгтэй байна уу. Гэхдээ ерөнхийдөө ямар ч үйлдэл хийх шаардлагагүй бүх зүйл лог руу ордог.
Энэ бүхний сөрөг үр дагавар нь бид ямар үйл явдалд ямар арга хэмжээ авах шаардлагатайг тодорхойлж, эдгээр үйлдлүүд ямар байх ёстойг сайтар тодорхойлсон бол үйлдлийг автоматжуулж болно гэсэн үг. Энэ нь юу болох вэ. Бид сэрэмжлүүлэгээс гардаг. Үйлдэлд орцгооё. Бид энэ үйлдлийн тайлбар руу очно. Тэгээд бид автоматжуулалт руу шилждэг. Өөрөөр хэлбэл аливаа автоматжуулалт нь үйл явдалд хариу үйлдэл үзүүлэхээс эхэлдэг.
Мониторингоос бид Ажиглах чадвар гэдэг нэр томъёо руу шилждэг. Мөн сүүлийн хэдэн жил энэ үгийн эргэн тойронд бага зэрэг шуугиан тарьж байсан. Цөөн хүн контекстээс гадуур юу гэсэн үг болохыг ойлгодог. Гэхдээ гол зүйл бол Ажиглах чадвар нь системийн ил тод байдлын хэмжүүр юм. Хэрэв ямар нэг зүйл буруу болвол яг юу нь буруу болсныг, тухайн үед системийн төлөв байдал ямар байсныг хэр хурдан тодорхойлох боломжтой. Кодын хувьд: аль функц амжилтгүй болсон, аль үйлчилгээ амжилтгүй болсон. Ямар төлөв байсан, жишээ нь, дотоод хувьсагч, тохиргоо. Дэд бүтцийн хувьд энэ нь боломжийн бүсэд ямар нэгэн гэмтэл гарсан бөгөөд хэрэв танд ямар нэгэн Kubernetes суулгасан бол аль хэсэгт доголдол гарсан, подвол ямар байдалтай байсан бэ. Үүний дагуу Observability нь MTTR-тэй шууд холбоотой байдаг. Үйлчилгээний Ажиглах чадвар өндөр байх тусам алдааг тодорхойлоход хялбар, алдааг засахад хялбар, алдааг автоматжуулахад хялбар, MTTR бага байх болно.
Дахин жижиг компаниуд руу шилжиж, одоо ч гэсэн багийн хэмжээг хэрхэн шийдвэрлэх, жижиг баг тусдаа SRE хөлслөх шаардлагатай эсэхийг асуух нь маш түгээмэл байдаг. Энэ талаар арай эрт ярьсан. Гарааны бизнес эсвэл жишээлбэл, багийг хөгжүүлэх эхний үе шатанд энэ нь огт шаардлагагүй, учир нь SRE нь шилжилтийн үүрэг гүйцэтгэж болно. Энэ нь багийг бага зэрэг сэргээх болно, учир нь ядаж олон янз байдал бий. Үүнээс гадна энэ нь өсөлтийг дагаад ерөнхийдөө SRE-ийн үүрэг хариуцлага эрс өөрчлөгдөхөд хүмүүсийг бэлтгэх болно. Хэрэв та хүн ажилд авбал мэдээж түүнд ямар нэгэн хүлээлт бий. Мөн эдгээр хүлээлт цаг хугацааны явцад өөрчлөгдөхгүй, гэхдээ шаардлага маш их өөрчлөгдөх болно. Тиймээс SRE-г хэрхэн хөлслөх нь эхний шатанд нэлээд хэцүү байдаг. Өөрийгөө өсгөх нь илүү хялбар байдаг. Гэхдээ энэ талаар бодох нь зүйтэй.
Цорын ганц үл хамаарах зүйл бол өсөлтийн маш хатуу, нарийн тодорхойлогдсон шаардлага байж болох юм. Өөрөөр хэлбэл, гарааны бизнесийн хувьд энэ нь хөрөнгө оруулагчдын дарамт шахалт, өсөлтийг хэд хэдэн удаа урьдчилан таамаглаж магадгүй юм. Дараа нь SRE ажилд авах нь үндэслэлтэй байж болох тул үндсэндээ үндэслэлтэй юм. Бидэнд өсөлтөд тавигдах шаардлага бий, ийм өсөлтөөр юу ч тасрахгүй гэдгийг хариуцах хүн хэрэгтэй байна.
Бас нэг асуулт. Хэд хэдэн удаа хөгжүүлэгчид туршилтыг давсан функцийг таслан зогсоовол юу хийх вэ, гэхдээ үйлдвэрлэлийг эвдэж, суурийг ачаалж, бусад функцуудыг эвдэж, ямар процессыг хэрэгжүүлэх вэ. Үүний дагуу энэ тохиолдолд алдааны төсөв гарч ирдэг. Мөн зарим үйлчилгээ, зарим функцийг үйлдвэрлэлд туршиж үзсэн. Цөөн тооны хэрэглэгчид хэдийнэ үйлдвэрлэгдээд байгаа хэдий ч ямар нэг зүйл эвдэрвэл, тухайлбал, нийт хэрэглэгчдийн хагас хувьд нь энэ нь ямар нэгэн зүйл эвдэрсэн тохиолдолд энэ нь шаардлага хангасан хэвээр байх болно гэсэн хүлээлттэй байгаа бол энэ нь канарей байж болно. алдааны төсөв. Үүний дагуу, тийм ээ, алдаа гарах болно, зарим хэрэглэгчдийн хувьд бүх зүйл эвдрэх болно, гэхдээ энэ нь хэвийн зүйл гэж бид аль хэдийн хэлсэн.
SRE хэрэгслүүдийн талаар асуулт байсан. Өөрөөр хэлбэл, SRE-д бусад бүх хүмүүс ашиглахгүй байх ямар нэг зүйл байдаг уу? Үнэн хэрэгтээ өндөр мэргэшсэн хэрэгслүүд байдаг, жишээлбэл, ачааллыг дуурайдаг эсвэл канарын A / B тест хийдэг програм хангамж байдаг. Гэхдээ үндсэндээ SRE хэрэгсэл нь таны хөгжүүлэгчид аль хэдийн ашиглаж байгаа зүйл юм. Учир нь SRE нь хөгжүүлэлтийн багтай шууд харилцдаг. Хэрэв танд өөр хэрэгсэл байгаа бол синхрончлоход цаг хугацаа шаардагдах болно. Ялангуяа SRE нь том багуудад, хэд хэдэн баг байж болох томоохон компаниудад ажилладаг бол энэ нь компанийг хамарсан стандартчилал нь энд маш их тус болно, учир нь 50 багт 50 өөр хэрэгслийг ашигладаг бол энэ нь SRE тэдгээрийг мэддэг байх ёстой гэсэн үг юм. бүгд. Мөн энэ нь мэдээжийн хэрэг хэзээ ч тохиолдохгүй. Мөн ажлын чанар, дор хаяж зарим багуудын хяналтын чанар мэдэгдэхүйц буурах болно.
Манай вебинар өндөрлөх гэж байна. Би хэд хэдэн үндсэн зүйлийг хэлж чадсан. Мэдээжийн хэрэг, SRE-ийн талаар нэг цагийн дотор юу ч хэлж, ойлгох боломжгүй. Гэхдээ би энэ сэтгэлгээний гол гол санааг илэрхийлж чадсан гэж найдаж байна. Дараа нь хэрэв сонирхож байгаа бол энэ сэдвийг судлах, бие даан суралцах, бусад хүмүүс, бусад компаниуд үүнийг хэрхэн хэрэгжүүлж байгааг харах боломжтой болно. Үүний дагуу XNUMX-р сарын эхээр Slurm SRE дээр бидэн дээр ирээрэй.
Slurm SRE бол миний одоо ярьж байгаа зүйлийн талаар ярих гурван өдрийн эрчимжүүлсэн сургалт боловч илүү гүнзгий, бодит тохиолдлууд, дадлага, бүхэл бүтэн эрчимжүүлсэн сургалт нь практик ажилд чиглэгддэг. Хүмүүс багуудад хуваагдана. Та бүгд бодит хэрэг дээр ажиллах болно. Үүний дагуу бид Booking.com-ын багш Иван Круглов, Бен Тайлер нартай. Сан Францискогийн Google-ийн гайхалтай Евгений Бараббас бидэнд бий. Бас би чамд нэг юм хэлье. Тиймээс манайхыг зорин ирж үйлчлүүлээрэй.
Тиймээс, ном зүй. SRE-ийн талаархи лавлагаа байдаг. ижил ном дээр, эс тэгвээс Google-ийн бичсэн SRE-ийн тухай 2 ном дээр. Өөр нэг , нөхцөл, тэдгээрийн хэрэглээ нь арай илүү нарийвчилсан байдаг. Дараагийн 3 нь өөр өөр компаниудын SRE-ийн тайлан юм. Эхлээд - , энэ бол Google-ийн Бен сургагч багшийн үндсэн илтгэл юм. Хоёрдугаарт - . Гурав дахь нь дахин . Дөрөв дэх сурвалжлага , 5 оронд зөвхөн 190 гол SRE ажилтантай. Энэ бүгдийг харах нь маш сонирхолтой юм, учир нь DevOps нь өөр өөр компаниуд, бүр өөр багуудад тэс өөр зүйлийг илэрхийлдэгтэй адил SRE нь ижил хэмжээтэй компаниудад ч тэс өөр үүрэг хариуцлага хүлээдэг.
Эмх замбараагүй инженерчлэлийн зарчмуудын талаархи өөр 2 холбоос: , . Төгсгөлд нь "Гайхалтай жагсаалт" цувралын 3 жагсаалт байна тухай тухай . SRE дээрх жагсаалт нь үнэхээр асар том бөгөөд үүнийг бүгдийг нь үзэх шаардлагагүй, 200 орчим нийтлэл байдаг. Би тэндээс хүчин чадлын төлөвлөлт болон үхлийн дараах гэм зэмгүй байдлын тухай нийтлэлүүдийг санал болгож байна.
Сонирхолтой нийтлэл:
Энэ бүх хугацаанд намайг сонссонд баярлалаа. Та ямар нэг зүйл сурсан гэж найдаж байна. Танд илүү ихийг сурахад хангалттай материал байгаа гэж найдаж байна. Тэгээд уулзъя. Хоёрдугаар сард болно гэж найдаж байна.
Вебинарыг Эдуард Медведев зохион байгуулсан.
Жич: Унших дуртай хүмүүст зориулж Эдуард лавлагааны жагсаалтыг өгсөн. Практик дээр ойлгохыг илүүд үздэг хүмүүсийг урьж байна .
Эх сурвалж: www.habr.com