CTO-ийн ур чадварыг хоёр дахь удаагаа энэ үүргийг гүйцэтгэхэд л шалгадаг нь мэдэгдэж байна. Учир нь компанид хэдэн жил ажиллаж, үүнтэй хамт хувьсан өөрчлөгдөж, ижил соёлын хүрээнд аажмаар илүү хариуцлага хүлээх нь нэг хэрэг. Хуучин ачаа тээш, олон асуудалтай компанид техникийн захирлын албан тушаалд шууд орох нь өөр хэрэг юм.

Энэ утгаараа Леон Файрын туршлагыг хуваалцсан DevOpsConf, тэр шууд өвөрмөц биш, харин түүний туршлага, 20 жилийн турш туршиж үзсэн янз бүрийн дүрүүдийн тоогоор үржүүлсэн нь маш хэрэгтэй юм. Тайлбарын доор 90 гаруй хоногийн үйл явдлуудын он дараалал, өөр хэн нэгэнд тохиолдоход инээх нь таатай ч биечлэн уулзахад тийм ч таатай биш олон үлгэрүүд байна.

Леон орос хэлээр маш өнгөлөг ярьдаг тул танд 35-40 минут байвал видеог үзэхийг зөвлөж байна. Цаг хэмнэхийн тулд доорх хувилбарыг бичнэ үү.

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

Нэг сарын өмнө

Олон сайхан үлгэрийн нэгэн адил энэ түүх архинаас эхэлсэн. Бид найзуудтайгаа бааранд сууж байсан бөгөөд мэдээллийн технологийн мэргэжилтнүүдийн таамаглаж байсанчлан бүгд асуудлынхаа талаар уйлж байв. Тэдний нэг нь дөнгөж ажлаа сольж, технологи, хүмүүс, хамт олонтой холбоотой асуудлаа ярьж байв. Би сонсох тусам тэр намайг зүгээр л ажилд авах ёстой юм байна гэдгийг ойлгосон, учир нь энэ бол миний сүүлийн 15 жилийн турш шийдэж ирсэн асуудлууд юм. Би түүнд ингэж хэлээд маргааш нь ажлын орчинд уулзсан. Тус компанийг сургалтын стратеги гэж нэрлэдэг байв.

Багшлах стратеги нь маш бага насны хүүхдүүдэд төрсөнөөс гурван нас хүртэлх сургалтын хөтөлбөрийн зах зээлд тэргүүлэгч юм. Уламжлалт "цаасан" компани аль хэдийн 40 нас хүрсэн бол платформын дижитал SaaS хувилбар нь 10 жил болж байна.Харьцангуй саяхан дижитал технологийг компанийн стандартад нийцүүлэх үйл явц эхэлсэн. "Шинэ" хувилбар нь 2017 онд гарсан бөгөөд хуучин хувилбартай бараг адилхан байсан ч илүү муу ажилласан.

Хамгийн сонирхолтой нь энэ компанийн урсгалыг урьдчилан таамаглах боломжтой - өдрөөс өдөрт, жилээс жилд хэдэн хүн хэзээ ирэхийг маш тодорхой таамаглах боломжтой. Жишээлбэл, 13-15 цагийн хооронд цэцэрлэгийн бүх хүүхдүүд унтаж, багш нар мэдээлэл оруулж эхэлдэг. Энэ нь амралтын өдрүүдээс бусад өдөр бүр тохиолддог, учир нь амралтын өдрүүдэд бараг хэн ч ажилладаггүй.

Цаашид бага зэрэг харвал би янз бүрийн шалтгааны улмаас сонирхолтой байдаг жилийн хамгийн их ачаалалтай үед ажлаа эхэлсэн гэдгээ тэмдэглэх болно.

Дөнгөж 2 настай юм шиг байсан платформ нь 2008 оны ColdFusion & SQL Server гэсэн өвөрмөц стектэй байв. ColdFusion бол 90-ээд оны дундуур гарч ирсэн аж ахуйн нэгжийн PHP бөгөөд тэр цагаас хойш би энэ талаар огт сонсоогүй юм байна. Мөн: Ruby, MySQL, PostgreSQL, Java, Go, Python байсан. Гэхдээ гол цул нь ColdFusion болон SQL Server дээр ажиллаж байсан.

Асуудал

Компанийн ажилчидтай ажил, ямар асуудал тулгарсан талаар ярилцах тусам асуудал нь зөвхөн техникийн шинж чанартай биш гэдгийг ойлгосон. За, технологи нь хуучирсан - тэд үүн дээр ажиллаагүй ч баг, үйл явцтай холбоотой асуудал гарсан тул компани үүнийг ойлгож эхэлсэн.

Уламжлал ёсоор тэдний техникчид буланд суугаад ямар нэгэн ажил хийдэг. Гэвч улам олон бизнес дижитал хувилбараар дамжиж эхлэв. Тиймээс намайг ажилд орохоос өмнөх сүүлийн жил компанид шинэ хүмүүс гарч ирэв: ТУЗ, CTO, CPO, QA захирал. Энэ нь тус компани технологийн салбарт хөрөнгө оруулалт хийж эхэлсэн.

Хүнд өвийн ул мөр нь зөвхөн системд байсангүй. Тус компани нь өв залгамжлалын үйл явц, өв залгамжлагч хүмүүс, өв соёлтой байсан. Энэ бүхнийг өөрчлөх шаардлагатай байсан. Энэ нь уйтгартай биш байх гэж бодсон бөгөөд үүнийг туршиж үзэхээр шийдсэн.

Хоёр хоногийн өмнө

Шинэ ажил эхлэхээс хоёр хоногийн өмнө би оффис дээр ирж, сүүлийн бичиг баримтыг бөглөж, багтай уулзаж, тухайн үед баг нь асуудалтай тулгараад байгааг олж мэдэв. Энэ нь хуудас ачаалах дундаж хугацаа 4 секунд, өөрөөр хэлбэл 2 дахин өссөн байв.

Графикаас харахад ямар нэгэн зүйл болсон бөгөөд юу нь тодорхойгүй байна. Асуудал нь дата төв дэх сүлжээний хоцролт байсан нь тогтоогдсон: өгөгдлийн төв дэх 5 мс хоцролт нь хэрэглэгчдийн хувьд 2 секунд болж хувирав. Яагаад ийм болсныг би мэдэхгүй байсан ч ямар ч тохиолдолд асуудал мэдээллийн төвд байгаа нь тодорхой болсон.

Эхний өдөр

Хоёр хоног өнгөрч, ажлын эхний өдөр л асуудал арилаагүй байгааг олж мэдэв.

Хоёр өдрийн турш хэрэглэгчдийн хуудас дунджаар 4 секундэд ачаалагдсан байна. Асуудал юу болохыг тэд олсон эсэхийг би асууж байна.

- Тийм ээ, бид тасалбар нээсэн.
- БА?
- За, тэд бидэнд хариу өгөөгүй байна.

Дараа нь би өмнө нь ярьж байсан бүх зүйл бол миний тэмцэх ёстой мөсөн уулын өчүүхэн хэсэг гэдгийг ойлгосон.

Үүнд маш сайн нийцсэн сайн ишлэл байдаг:

"Заримдаа технологийг өөрчлөхийн тулд та байгууллагаа өөрчлөх хэрэгтэй."

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

Гурав дахь өдөр

Тиймээс ачаалал 4 секунд үргэлжилдэг бөгөөд 13-аас 15 хүртэл хамгийн том оргилууд байдаг.

Гурав дахь өдөр энэ хугацаанд татаж авах хурд дараах байдалтай байв.

Миний бодлоор юу ч бүтсэнгүй. Бусдын өнцгөөс харахад энэ нь ердийнхөөс арай удаан ажиллаж байв. Гэхдээ ийм зүйл тохиолддоггүй - энэ бол ноцтой асуудал юм.

Би багийг итгүүлэхийг оролдсон бөгөөд тэд илүү олон сервер хэрэгтэй гэж хариулав. Энэ нь мэдээжийн хэрэг асуудлыг шийдэх шийдэл боловч энэ нь үргэлж цорын ганц бөгөөд хамгийн үр дүнтэй байдаггүй. Яагаад хангалттай сервер байхгүй байна вэ, замын хөдөлгөөний хэмжээ хэд вэ гэж асуув. Би өгөгдлийг экстраполяци хийж үзээд бидэнд секундэд ойролцоогоор 150 хүсэлт ирдэг бөгөөд энэ нь зарчмын хувьд боломжийн хязгаарт багтаж байгааг олж мэдэв.

Гэхдээ та зөв хариулт авахаасаа өмнө зөв асуулт асуух хэрэгтэй гэдгийг мартаж болохгүй. Миний дараагийн асуулт бол: Бид хэдэн урд сервертэй вэ? "Намайг бага зэрэг гайхшруулсан" гэсэн хариулт бидэнд 17 сервертэй байсан!

- Би асуухаас ичиж байна, гэхдээ 150-г 17-д хуваасан нь 8 орчим болж байна уу? Та сервер бүр секундэд 8 хүсэлтийг зөвшөөрдөг, маргааш секундэд 160 хүсэлт ирвэл бидэнд 2 сервер хэрэгтэй болно гэж хэлж байна уу?

Мэдээжийн хэрэг, бидэнд нэмэлт сервер хэрэггүй байсан. Шийдэл нь код дотор байсан бөгөөд гадаргуу дээр:

var currentClass = classes.getCurrentClass();
return currentClass;

Функц байсан getCurrentClass(), учир нь сайт дээрх бүх зүйл ангийн хүрээнд ажилладаг - энэ нь зөв. Үүний тулд хуудас бүр дээр нэг функц байсан 200 гаруй хүсэлт.

Үүний шийдэл нь маш энгийн байсан тул та юу ч дахин бичих шаардлагагүй байсан: зүгээр л ижил мэдээллийг дахин бүү асуу.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Гурав дахь өдрөө л гол асуудлаа олсон гэж шийдсэн болохоор би маш их баярласан. Би гэнэн байсан ч энэ бол олон асуудлын нэг л байсан.

Гэхдээ энэ анхны асуудлыг шийдсэнээр график хамаагүй доошилсон.

Үүний зэрэгцээ бид бусад оновчлолуудыг хийж байсан. Засаж болох зүйл олон байсан. Жишээлбэл, гурав дахь өдөр би системд кэш байгааг олж мэдсэн (эхэндээ бүх хүсэлт мэдээллийн сангаас шууд ирж байна гэж бодсон). Би кэшийг бодохдоо стандарт Redis эсвэл Memcached гэж боддог. Гэхдээ би л тэгж бодож байсан, учир нь тэр систем нь MongoDB болон SQL серверийг кэш хийхдээ ашигладаг байсан - яг л өгөгдлийг уншсан.

Арав дахь өдөр

Эхний долоо хоногт би яг одоо шийдэх шаардлагатай асуудлуудыг шийдсэн. Хоёр дахь долоо хоногт хаа нэгтээ би багтайгаа харилцах, юу болж байгааг, бүх үйл явц хэрхэн өрнөж байгааг харахаар анх удаагаа стэнд дээр ирсэн.

Сонирхолтой зүйл дахин нээгдэв. Багийн бүрэлдэхүүнд: 18 хөгжүүлэгч; 8 шалгагч; 3 менежер; 2 архитектор. Тэгээд бүгдээрээ нийтлэг зан үйлд оролцдог байсан, өөрөөр хэлбэл өглөө бүр 30 гаруй хүн зогсож, юу хийснээ ярьдаг байсан. Хурал 5, 15 минут үргэлжилээгүй нь ойлгомжтой. Хүн бүр өөр өөр систем дээр ажилладаг тул хэн ч хэнийг ч сонсоогүй. Энэ маягт дээр үс засалт хийхэд зориулж цагт 2-3 тасалбар аль хэдийн сайн үр дүн байсан.

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

Үүний үр дүнд бид дараахь зүйлийг авсан.

• Босгоц, жагсаал цуглааныг багасгах.
• Бүтээгдэхүүний талаархи мэдлэг.
• Өмчлөлийн мэдрэмж. Хүмүүс системтэй байнга эргэлздэг байсан бол өөр хэн нэгэн алдаатай ажиллах хэрэгтэй болно гэдгийг мэддэг байсан, гэхдээ өөрсдөө биш.
• Бүлэг хоорондын хамтын ажиллагаа. Өмнө нь QA программистуудтай тийм ч их харилцдаггүй, бүтээгдэхүүн нь өөрийнхөөрөө байсан гэх мэтийг хэлэх нь илүүц биз. Одоо тэд нэгдмэл үүрэг хариуцлагатай болсон.

Бид голчлон үр ашиг, бүтээмж, чанарт анхаарлаа хандуулсан - эдгээр нь багийг өөрчлөх замаар шийдвэрлэхийг оролдсон асуудлууд юм.

Арван нэг дэх өдөр

Багийн бүтцийг өөрчлөх явцад би хэрхэн тоолохыг олж мэдсэн түүхоноо. 1 SP нь нэг өдөртэй тэнцүү байсан бөгөөд тасалбар бүр нь хөгжүүлэлт болон QA-д зориулсан SP, өөрөөр хэлбэл дор хаяж 2 SP-ийг агуулж байсан.

Би үүнийг яаж олж мэдсэн бэ?

Бид алдаа оллоо: тайлангуудын аль нэгэнд тайлан гаргах шаардлагатай хугацааны эхлэх, дуусах огноог оруулсан бол сүүлийн өдрийг тооцдоггүй. Энэ нь хүсэлтийн хаа нэгтээ <= биш, харин зүгээр л < байсан. Энэ бол гурван өгүүллэгийн цэг гэж надад хэлсэн 3 хоног.

Үүний дараа бид:

• Өгүүллийн онооны үнэлгээний системийг шинэчилсэн. Одоо системээр дамжуулж болох жижиг алдаануудыг зассан нь хэрэглэгчдэд илүү хурдан хүрдэг.
• Бид хөгжүүлэлт, туршилтын зорилгоор холбогдох тасалбаруудыг нэгтгэж эхэлсэн. Өмнө нь тасалбар бүр, алдаа бүр нь өөр зүйлтэй холбоогүй хаалттай экосистем байсан. Нэг хуудсан дээрх гурван товчлуурыг солих нь нэг хуудсанд нэг автомат шалгалтын оронд гурван өөр QA процесс бүхий гурван өөр тасалбар байж болох юм.
• Бид хөдөлмөрийн зардлыг тооцох арга барил дээр хөгжүүлэгчидтэй хамтран ажиллаж эхэлсэн. Гурван өдөр нэг товчлуур солих нь инээдтэй биш юм.

Хорь дахь өдөр

Эхний сарын дундуур хаа нэгтээ нөхцөл байдал бага зэрэг тогтворжиж, би юу болж байгааг олж мэдээд, ирээдүйгээ харж, урт хугацааны шийдлүүдийн талаар бодож эхэлсэн.

Урт хугацааны зорилго:

• Удирдах платформ. Хуудас бүр дээрх хэдэн зуун хүсэлт нь ноцтой биш юм.
• Урьдчилан таамаглах чиг хандлага. Эхний ээлжинд бусад хэмжигдэхүүнтэй уялдаагүй замын хөдөлгөөний оргил үе үе үе байсан - бид яагаад ийм зүйл болсныг ойлгож, урьдчилан таамаглаж сурах хэрэгтэй байв.
• Платформын өргөтгөл. Бизнес байнга хөгжиж, улам олон хэрэглэгчид ирж, урсгал нэмэгдэж байна.

Өмнө нь ихэвчлэн ингэж хэлдэг байсан: "Бүх зүйлийг [хэл/хүрээнд] дахин бичье, бүх зүйл илүү сайн ажиллах болно!"

Ихэнх тохиолдолд энэ нь ажиллахгүй, дахин бичих нь сайн хэрэг. Тиймээс бид бизнесийн зорилгодоо хэрхэн хүрэхийг (бид юу хийх, яагаад) алхам алхмаар харуулсан тодорхой стратеги бүхий замын зураглалыг бий болгох шаардлагатай болсон.

• төслийн эрхэм зорилго, зорилгыг тусгасан;
• гол зорилгоо эрэмбэлэх;
• тэдгээрт хүрэх хуваарийг агуулсан.

Үүнээс өмнө ямар нэгэн өөрчлөлт хийх зорилгын талаар багийнхантай хэн ч яриагүй. Энэ нь амжилтын зөв хэмжүүрийг шаарддаг. Компанийн түүхэнд анх удаа бид техникийн бүлгийн KPI-ийг тогтоосон бөгөөд эдгээр үзүүлэлтүүд нь зохион байгуулалттай холбоотой байв.

Өөрөөр хэлбэл, байгууллагын KPI-ийг багууд, багийн KPI-ийг тус тусын KPI-ууд дэмждэг. Үгүй бол технологийн KPI нь зохион байгуулалтынхтай давхцахгүй бол хүн бүр хөнжлөө өөр дээрээ татдаг.

Жишээлбэл, байгууллагын KPI-ийн нэг нь шинэ бүтээгдэхүүнээр дамжуулан зах зээлд эзлэх хувийг нэмэгдүүлэх явдал юм.

Илүү олон шинэ бүтээгдэхүүнтэй болох зорилтыг хэрхэн дэмжих вэ?

• Нэгдүгээрт, бид согогийг засахын оронд шинэ бүтээгдэхүүн боловсруулахад илүү их цаг зарцуулахыг хүсч байна. Энэ бол хэмжихэд хялбар логик шийдэл юм.
• Хоёрдугаарт, гүйлгээний хэмжээг нэмэгдүүлэхийг бид дэмжихийг хүсч байна, учир нь зах зээлд эзлэх хувь их байх тусам илүү олон хэрэглэгч, үүний дагуу урсгал нэмэгдэж байна.

Дараа нь бүлгийн хүрээнд гүйцэтгэж болох бие даасан KPI нь жишээлбэл, гол согогууд гарч ирдэг газарт байх болно. Хэрэв та энэ хэсэгт онцгой анхаарал хандуулвал согог хамаагүй бага байгаа эсэхийг шалгаарай, дараа нь шинэ бүтээгдэхүүн боловсруулах, дахин байгууллагын KPI-ийг дэмжих хугацаа нэмэгдэх болно.

Тиймээс шийдвэр бүр, түүний дотор кодыг дахин бичих нь компанийн бидэнд тавьсан тодорхой зорилтуудыг (байгууллагын өсөлт, шинэ боломжууд, ажилд авах) дэмжих ёстой.

Энэ үйл явцын үеэр нэгэн сонирхолтой зүйл гарч ирсэн бөгөөд энэ нь зөвхөн техникчдэд төдийгүй ерөнхийдөө компанид мэдээ болсон: бүх тасалбарууд дор хаяж нэг KPI дээр төвлөрөх ёстой. Өөрөөр хэлбэл, хэрэв бүтээгдэхүүн нь шинэ функц хийхийг хүсч байгаа бол "Энэ функц нь ямар KPI-ийг дэмждэг вэ?" Гэсэн эхний асуултыг асуух ёстой. Хэрэв тийм биш бол уучлаарай - энэ нь шаардлагагүй функц юм шиг санагдаж байна.

Гучин өдөр

Сарын сүүлээр би өөр нэг нюансыг олж мэдсэн: манай Операторын багийн хэн ч бидний үйлчлүүлэгчидтэй байгуулсан гэрээг хэзээ ч харж байгаагүй. Та яагаад харилцагчдыг харах хэрэгтэйг асууж магадгүй.

• Нэгдүгээрт, SLA-г гэрээнд заасан байдаг.
• Хоёрдугаарт, SLA нь бүгд өөр өөр байдаг. Үйлчлүүлэгч бүр өөр өөрийн шаардлагаа ирсэн бөгөөд борлуулалтын алба харалгүй гарын үсэг зурсан.

Өөр нэг сонирхолтой нюанс бол хамгийн том үйлчлүүлэгчдийн нэгтэй хийсэн гэрээнд платформоор дэмжигдсэн бүх програм хангамжийн хувилбарууд нь n-1, өөрөөр хэлбэл хамгийн сүүлийн хувилбар биш, харин эцсийн хувилбар байх ёстой гэж заасан байдаг.

Хэрэв платформ нь 1-р сард огт дэмжигдэхгүй болсон ColdFusion болон SQL Server 2008 дээр суурилсан бол бид n-XNUMX-ээс хэр хол байсан нь тодорхой байна.

Дөчин тав дахь өдөр

Хоёр дахь сарын дундуур надад суугаад хийх хангалттай хугацаа байсан үнэ цэнэурсгалзураглал бүх үйл явцын хувьд бүрэн. Эдгээр нь бүтээгдэхүүн бүтээхээс эхлээд хэрэглэгчдэд хүргэх хүртэл зайлшгүй хийх шаардлагатай алхмууд бөгөөд тэдгээрийг аль болох нарийвчлан тайлбарлах шаардлагатай.

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

Би үүнийг хийх үед хоёр зүйл миний анхаарлыг татав:

• QA-аас хөгжүүлэгчдэд буцааж өгсөн тасалбарын өндөр хувь;
• татах хүсэлтийг хянан үзэх нь хэтэрхий удсан.

Асуудлын гол нь эдгээр нь: Энэ нь маш их цаг хугацаа шаардаж байх шиг байна, гэхдээ бид хэр удаан үргэлжлэхийг мэдэхгүй байна.

"Та хэмжиж чадахгүй зүйлээ сайжруулж чадахгүй."

Асуудал хэр ноцтой байгааг хэрхэн зөвтгөх вэ? Энэ нь өдөр, цагийг дэмий үрдэг үү?

Үүнийг хэмжихийн тулд бид Жира процесст хэд хэдэн алхмыг нэмсэн: тасалбар бүр хэр удаан хүлээгдэж, хэдэн удаа тодорхой алхам руу буцаж ирэхийг хэмжихийн тулд "deady for dev" болон "ready to QA".

Дунджаар шалгах тасалбар хэр их байгааг мэдэхийн тулд бид "хяналт"-ыг нэмсэн бөгөөд үүнээс та бүжиглэж эхлэх боломжтой. Бидэнд системийн хэмжүүрүүд байсан, одоо бид шинэ хэмжүүр нэмж, хэмжиж эхлэв:

• Процессын үр ашиг: гүйцэтгэл болон төлөвлөсөн/хүргэгдсэн.
• Процессын чанар: согогийн тоо, QA-аас гарсан согог.

Энэ нь юу сайн болж, юу нь болохгүй байгааг ойлгоход үнэхээр тусалдаг.

Тав дахь өдөр

Энэ бүхэн мэдээжийн хэрэг сайн бөгөөд сонирхолтой боловч хоёр дахь сарын эцэс гэхэд би ийм хэмжүүрийг хүлээж байгаагүй ч гэсэн зарчмын хувьд урьдчилан таамаглах боломжтой зүйл тохиолдсон. Дээд удирдлага солигдсон учраас хүмүүс гарч эхэлсэн. Удирдлагад шинэ хүмүүс орж ирээд бүх зүйлийг өөрчилж, хуучин хүмүүс ажлаасаа гарсан. Тэгээд ихэвчлэн хэдэн жилийн настай компанид бүгд найз нөхөд, бүгд бие биенээ мэддэг.

Энэ нь хүлээгдэж байсан ч цомхотголын цар хүрээ гэнэтийн байсан. Тухайлбал, нэг долоо хоногийн дотор багийн хоёр удирдагч нэгэн зэрэг өөрийн хүсэлтээр огцрох өргөдлөө өгсөн. Тиймээс би бусад асуудлуудыг мартаад зогсохгүй анхаарлаа хандуулах хэрэгтэй болсон баг бүрдүүлэх. Энэ бол урт бөгөөд шийдвэрлэхэд хэцүү асуудал боловч би үлдсэн хүмүүсийг (эсвэл тэдний ихэнхийг) аврахыг хүссэн тул үүнийг шийдвэрлэх шаардлагатай болсон. Багийн ёс суртахууныг хадгалахын тулд хүмүүс явсанд ямар нэгэн байдлаар хариу үйлдэл үзүүлэх шаардлагатай байв.

Онолын хувьд энэ нь сайн хэрэг: багийн ур чадварыг үнэлж, боловсон хүчнийг сольж чадах бүрэн карттай шинэ хүн орж ирдэг. Үнэндээ та олон шалтгааны улмаас шинэ хүмүүсийг авчирч чадахгүй. Тэнцвэр үргэлж хэрэгтэй байдаг.

• Хуучин ба шинэ. Эрхэм зорилгоо өөрчилж, дэмжиж чаддаг ахмадуудыг авч үлдэх хэрэгтэй. Гэхдээ үүнтэй зэрэгцэн бид шинэ цус авчрах хэрэгтэй, бид энэ талаар хэсэг хугацааны дараа ярих болно.
• Туршлага. Бидэнтэй хамтран ажиллах хүсэл эрмэлзэлтэй, сайн залуучуудтай их ярилцсан. Гэхдээ бага насныхныг дэмжиж, тэдэнд зөвлөгчөөр ажиллах ахмадууд хангалтгүй байсан тул би тэднийг авч чадаагүй. Эхлээд дээд, дараа нь залуучуудыг элсүүлэх шаардлагатай байв.
• Лууван ба саваа.

Тэнцвэр гэж юу вэ, түүнийг яаж барих вэ, хэдэн хүн байлгах вэ, хэр их шахах вэ гэдэг асуултад надад олигтой хариулт алга. Энэ бол цэвэр хувь хүний ​​үйл явц юм.

Тавин нэг дэх өдөр

Би хэн болохыг ойлгохын тулд багийг анхааралтай ажиглаж эхэлсэн бөгөөд дахин нэг удаа санав:

"Ихэнх асуудал бол хүмүүсийн асуудал юм."

Багийн хувьд Dev болон Ops хоёуланд нь гурван том асуудал байгааг би олж мэдсэн:

• Одоогийн нөхцөл байдалд сэтгэл хангалуун байна.
• Хариуцлага дутмаг - Учир нь хэн ч бизнест нөлөөлөхийн тулд жүжигчдийн ажлын үр дүнг авчирч байгаагүй.
• Өөрчлөлтөөс айдаг.

Өөрчлөлт үргэлж таныг тав тухтай бүсээс гаргадаг бөгөөд залуу хүмүүс байх тусам өөрчлөлтөд дургүй байдаг, учир нь тэд яагаад гэдгийг ойлгохгүй, яаж хийхийг ойлгохгүй байна. Миний сонссон хамгийн түгээмэл хариулт бол "Бид хэзээ ч ийм зүйл хийж байгаагүй." Түүгээр ч барахгүй энэ нь бүрэн утгагүй байдалд хүрсэн - хэн нэгний уур хилэнгүйгээр өчүүхэн өөрчлөлт гарахгүй. Өөрчлөлт нь тэдний ажилд хичнээн их нөлөөлсөн ч хүмүүс: "Үгүй, яагаад? Энэ бүтэхгүй."

Гэхдээ та юуг ч өөрчлөхгүйгээр сайжирч чадахгүй.

Би нэг ажилтантай үнэхээр утгагүй яриа өрнүүлсэн бөгөөд би түүнд оновчлолын талаархи санаагаа хэлсэн бөгөөд тэр надад хэлэв.
- Өө, та өнгөрсөн жил бидэнд юу байгааг хараагүй!
- Тэгээд юу гэж?
"Одоо өмнөхөөсөө хамаагүй дээр болсон."
-Тэгэхээр илүү дээрдэж чадахгүй байна уу?
- Юуны төлөө?

Сайн асуулт - яагаад? Одоо өмнөхөөсөө дээрдсэн юм шиг, тэгвэл бүх зүйл хангалттай сайхан байна. Энэ нь хариуцлагагүй байдалд хүргэдэг бөгөөд энэ нь зарчмын хувьд туйлын хэвийн үзэгдэл юм. Миний хэлсэнчлэн техникийн хэсэг жаахан хоцрогдсон байсан. Тэд оршин байх ёстой гэж компани итгэж байсан ч стандартыг хэн ч хэзээ ч тогтоож байгаагүй. Техникийн дэмжлэг нь SLA-г хэзээ ч харж байгаагүй тул энэ нь бүлгийн хувьд "хүлээн зөвшөөрөгдөхүйц" байсан (мөн энэ нь надад хамгийн их нөлөөлсөн):

• 12 секунд ачаалах;
• Хувилбар бүрт 5-10 минутын завсарлага;
• Чухал асуудлуудыг шийдвэрлэхэд өдөр, долоо хоног шаардагдана;
• 24x7 / дуудлагаар жижүүрийн дутагдалтай.

Яагаад бид үүнийг илүү сайн хийж болохгүй гэж хэн ч хэзээ ч асууж байгаагүй, ийм байх албагүй гэдгийг хэн ч ухаарч байгаагүй.

Урамшууллын хувьд дахиад нэг асуудал гарсан: туршлага дутмаг. Ахмадууд яваад, үлдсэн залуу баг нь өмнөх засаглалын үед өсч торниж, түүндээ хордсон.

Энэ бүхнээс гадна хүмүүс бүтэлгүйтэх, чадваргүй харагдахаас айдаг байсан. Энэ нь нэгдүгээрт, тэд ямар ч тохиолдолд тусламж гуйгаагүй. Бид хэчнээн удаа бүлгээрээ болон ганцаарчлан ярилцаж, би "Яаж хийхээ мэдэхгүй байгаа бол асуулт асуу" гэж хэлсэн. Би өөртөө итгэлтэй, ямар ч асуудлыг шийдэж чадна гэдгээ мэдэж байгаа ч үүнд цаг хугацаа хэрэгтэй. Тиймээс 10 минутын дотор яаж шийдэх вэ гэдгийг мэддэг хүнээс асуувал асууя. Туршлага бага байх тусмаа өөрийгөө чадваргүйд тооцно гэж бодоод асуухаас айдаг.

Асуулт асуухаас айдаг энэ айдас нь сонирхолтой хэлбэрээр илэрдэг. Жишээлбэл, та: "Та энэ ажлыг яаж хийж байна вэ?" Гэж асууна. - "Хоёр цаг үлдлээ, би аль хэдийн дуусгаж байна." Маргааш нь дахиад асуувал бүх зүйл сайхан байна гэсэн хариу ирдэг, гэхдээ нэг асуудал байсан, өдрийн эцэс гэхэд бэлэн болно. Өөр нэг өдөр өнгөрч, таныг хананд наалдаж, хэн нэгэнтэй ярихыг албадах хүртэл энэ хэвээр байна. Хүн аливаа асуудлыг өөрөө шийдэхийг хүсдэг, хэрэв тэр өөрөө шийдэхгүй бол том бүтэлгүйтэл болно гэдэгт итгэдэг.

Тийм учраас л хөгжүүлэгчид тооцооллыг хэтрүүлсэн. Яг л тэр анекдот байсан, тэд тодорхой үүрэг даалгаврын талаар ярилцаж байхад тэд надад ийм тоо өгсөн нь би их гайхсан. Хөгжүүлэгчийн тооцоололд хөгжүүлэгч тасалбарыг QA-аас буцаах цаг, учир нь тэнд алдаа олно, PR-д шаардагдах хугацаа, хянаж үзэх ёстой хүмүүсийн цагийг багтаасан гэж надад хэлсэн. Энэ нь завгүй байх болно - өөрөөр хэлбэл бүх зүйл, боломжтой бүх зүйл.

Хоёрдугаарт, чадваргүй харагдахаас айдаг хүмүүс хэт дүн шинжилгээ хийх. Та яг юу хийх ёстойг хэлэхэд "Үгүй ээ, бид энэ талаар энд бодвол яах вэ?" Энэ утгаараа манай компани онцгой биш, энэ бол залуучуудын хувьд жишиг асуудал юм.

Үүний хариуд би дараах практикийг танилцуулав.

• Дүрэм 30 минут. Хэрэв та хагас цагийн дотор асуудлыг шийдэж чадахгүй бол хэн нэгнээс тусламж хүс. Энэ нь янз бүрийн түвшинд амжилттай ажилладаг, учир нь хүмүүс асуугаагүй хэвээр байгаа ч ядаж л үйл явц эхэлсэн.
• Мөн чанараас бусад бүх зүйлийг устга, даалгаврыг дуусгах эцсийн хугацааг тооцоолохдоо, өөрөөр хэлбэл, код бичихэд хэр хугацаа шаардагдахыг анхаарч үзээрэй.
• Насан туршдаа суралцах Хэт их дүн шинжилгээ хийдэг хүмүүст. Энэ бол зүгээр л хүмүүстэй байнгын ажил.

Жаран дахь өдөр

Энэ бүхнийг хийж байх хооронд төсвөө гаргах цаг болсон. Мэдээжийн хэрэг, би мөнгөө хаана зарцуулсан талаар олон сонирхолтой зүйлийг олж мэдсэн. Жишээлбэл, бид нэг үйлчлүүлэгчийн ашигладаг FTP сервер бүхий тусдаа мэдээллийн төвд бүхэл бүтэн тавиуртай байсан. Энэ нь "... бид нүүсэн, гэхдээ тэр хэвээрээ байсан, бид түүнийг өөрчлөөгүй." 2 жилийн өмнө байсан.

Ялангуяа үүлэн үйлчилгээний тухай хуулийн төсөл сонирхол татсан. Үүлэн тооцооны гол шалтгаан нь амьдралдаа анх удаа серверт хязгааргүй нэвтрэх эрхтэй хөгжүүлэгчид гэдэгт би итгэдэг. Тэд "Надад туршилтын сервер өгөөч" гэж асуух шаардлагагүй, тэд өөрсдөө үүнийг авч болно. Нэмж дурдахад, хөгжүүлэгчид Facebook болон Netflix-д атаархах тийм гайхалтай системийг бүтээхийг үргэлж хүсдэг.

Гэхдээ хөгжүүлэгчид сервер худалдаж авах туршлагагүй, шаардлагатай серверийн хэмжээг тодорхойлох ур чадваргүй байдаг, учир нь тэдэнд өмнө нь хэрэггүй байсан. Мөн тэд ихэвчлэн өргөтгөх чадвар болон гүйцэтгэлийн ялгааг сайн ойлгодоггүй.

Бараа материалын үр дүн:

• Бид нэг дата төвөөс гарсан.
• Бид 3 бүртгэлийн үйлчилгээтэй гэрээгээ цуцалсан. Учир нь бидэнд 5 ширхэг байсан - ямар нэгэн зүйлээр тоглож эхэлсэн хөгжүүлэгч бүр шинээр авсан.
• 7 AWS системийг хаасан. Дахин хэлэхэд үхсэн төслүүдийг хэн ч зогсоосонгүй, тэд бүгд үргэлжлүүлэн ажиллав.
• Програм хангамжийн зардлыг 6 дахин бууруулсан.

Далан тав дахь өдөр

Цаг хугацаа өнгөрч, хоёр сар хагасын дараа би захирлуудын зөвлөлтэй уулзах хэрэгтэй болсон. Манай ТУЗ бусдаас дээр ч юм уу, муу ч юм биш, бүх ТУЗ-ийн нэгэн адил бүгдийг мэдэхийг хүсдэг. Хүмүүс хөрөнгө оруулалт хийж, бидний хийж байгаа зүйл нь тогтоосон KPI-д хэр нийцэж байгааг ойлгохыг хүсдэг.

Удирдах зөвлөл сар бүр маш их мэдээлэл авдаг: хэрэглэгчдийн тоо, тэдний өсөлт, ямар үйлчилгээ, хэрхэн ашигладаг, гүйцэтгэл, бүтээмж, эцэст нь хуудас ачаалах дундаж хурд.

Ганц асуудал бол дундаж нь цэвэр муу гэж би итгэдэг. Гэхдээ үүнийг ТУЗ-д тайлбарлана гэдэг маш хэцүү. Тэд жишээлбэл, секундэд ачаалах хугацааны тархалт биш харин нэгтгэсэн тоогоор ажиллахад дассан байдаг.

Үүнтэй холбогдуулан зарим сонирхолтой зүйлүүд байсан. Жишээлбэл, бид агуулгын төрлөөс хамааран тусдаа вэб серверүүдийн хооронд урсгалыг хуваах хэрэгтэй гэж би хэлсэн.

Өөрөөр хэлбэл, ColdFusion нь Jetty болон nginx-ээр дамжин хуудсуудыг ажиллуулдаг. Мөн зураг, JS болон CSS нь өөрийн тохиргоотой тусдаа nginx-ээр дамждаг. Энэ бол миний яриад байгаа нэлээд стандарт практик юм бичсэн хэдэн жилийн өмнө. Үүний үр дүнд зургууд илүү хурдан ачаалагддаг бөгөөд ... татаж авах дундаж хурд 200 мс-ээр нэмэгдсэн байна.

График нь Жеттитэй хамт ирдэг өгөгдөл дээр тулгуурлан бүтээгдсэн тул ийм зүйл болсон. Өөрөөр хэлбэл, хурдан контентыг тооцоололд оруулаагүй болно - дундаж үнэ цэнэ өссөн байна. Энэ нь бидэнд ойлгомжтой байсан, бид инээж байсан, гэхдээ бид ямар нэг зүйл хийж, 12% -иар муудсаныг ТУЗ-д яаж тайлбарлах вэ?

Наян тав дахь өдөр

Гурав дахь сарын сүүлчээр би огт тооцоолоогүй нэг зүйл байгааг ойлгосон: цаг хугацаа. Миний ярьсан бүхэн цаг хугацаа шаарддаг.

Энэ бол миний жинхэнэ долоо хоног тутмын хуанли - зүгээр л ажлын долоо хоног, тийм ч завгүй биш. Бүх зүйлд хангалттай хугацаа байдаггүй. Тиймээс, бэрхшээлийг даван туулахад туслах хүмүүсийг дахин элсүүлэх хэрэгтэй.

дүгнэлт

Энэ бүгд биш. Энэ түүхэнд бид бүтээгдэхүүнтэй хэрхэн ажиллаж, ерөнхий давалгааг тааруулах гэж оролдсон, техникийн дэмжлэгийг хэрхэн нэгтгэсэн, бусад техникийн асуудлуудыг хэрхэн шийдсэн талаар ч олж мэдсэнгүй. Жишээлбэл, бид мэдээллийн сангийн хамгийн том хүснэгтүүдийг ашигладаггүй гэдгийг би санамсаргүйгээр олж мэдсэн SEQUENCE. Бид өөрөө бичдэг функцтэй nextID, мөн энэ нь гүйлгээнд ашиглагддаггүй.

Бид удаан хугацаанд ярьж болох сая сая ижил төстэй зүйл байсан. Гэхдээ хэлэх ёстой хамгийн чухал зүйл бол соёл.

Энэ нь соёл эсвэл түүний дутагдал нь бусад бүх асуудалд хүргэдэг. Бид хүмүүс дараахь соёлыг бий болгохыг хичээж байна.

• бүтэлгүйтлээс айдаггүй;
• алдаанаасаа суралцах;
• бусад багуудтай хамтран ажиллах;
• санаачилга гаргах;
• хариуцлага хүлээх;
• үр дүнг зорилго болгон хүлээж авах;
• амжилтыг тэмдэглэж байна.

Үүнтэй хамт бусад бүх зүйл ирэх болно.

Леон Гал twitter дээр, Facebook-ийн мөн дээр дунд.

Өв залгамжлалын талаар хоёр стратеги байдаг: ямар ч үнээр хамаагүй түүнтэй ажиллахаас зайлсхийх эсвэл холбогдох бэрхшээлийг зоригтойгоор даван туулах. Бид в DevOpsConf Бид хоёр дахь замаар явж, үйл явц, арга барилаа өөрчилж байна. Бидэнтэй нэгдээрэй YouTube-ийн, захидлын жагсаалт и цахилгаан, мөн бид хамтдаа DevOps соёлыг хэрэгжүүлэх болно.

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