Нэгэн удаа бид цахим баримт бичгийн менежментийн системийг нэг объектын хэрэглэгчдэд нийлүүлж байсан. Тэгээд өөр объект руу. Бас нэг. Мөн дөрөв дэх, тав дахь нь. Бид маш их автсан тул 10 тараасан объектод хүрэв. Энэ нь маш сайн болсон... ялангуяа өөрчлөлтүүдийг хүргэх үед. Үйлдвэрлэлийн хэлхээнд хүргэх ажлын нэг хэсэг болох туршилтын системийн 5 хувилбар нь эцсийн дүндээ 10 цаг, 6-7 ажилтан шаарддаг. Ийм зардал биднийг аль болох ховор хүргэлтийг хийхэд хүргэсэн. Гурван жил ажилласны дараа бид тэвчиж чадалгүй төслийг нэг чимх DevOps-оор баяжуулахаар шийдсэн.
Одоо бүх туршилт 3 цагийн дотор явагддаг бөгөөд үүнд 3 хүн оролцдог: инженер, хоёр шалгагч. Сайжруулалтыг тоогоор тодорхой илэрхийлж, хүмүүсийн дуртай TTM-ийг багасгахад хүргэдэг. Бидний туршлагаас харахад DevOps-ийн ашиг тусыг хүртэх хэрэглэгчид үүнийг мэддэг хүмүүсээс илүү олон байдаг. Тиймээс, DevOps-ийг хүмүүст ойртуулахын тулд бид энгийн бүтээгчийг боловсруулсан бөгөөд энэ нийтлэлд бид илүү дэлгэрэнгүй ярих болно.
Одоо танд илүү дэлгэрэнгүй хэлье. Эрчим хүчний нэг компани 10 томоохон байгууламжид техникийн баримт бичгийн удирдлагын системийг нэвтрүүлж байна. DevOpsгүйгээр ийм хэмжээний төслүүдийг удирдах нь тийм ч хялбар биш, учир нь гар хөдөлмөрийн ихээхэн хэсэг нь ажлыг ихээхэн удаашруулж, чанарыг бууруулдаг - бүх гар ажиллагаа алдаатай байдаг. Нөгөөтэйгүүр, зөвхөн нэг суурилуулалттай төслүүд байдаг, гэхдээ бүх зүйл автоматаар, байнга, алдаагүй ажиллах шаардлагатай байдаг - жишээлбэл, томоохон цул байгууллагуудад ижил баримт бичгийн урсгалын системүүд. Үгүй бол хэн нэгэн тохиргоог гараар хийж, байршуулах зааврыг мартаж, үр дүнд нь үйлдвэрлэлд тохиргоо алдагдаж, бүх зүйл нурах болно.
Ихэнхдээ бид үйлчлүүлэгчтэй гэрээгээр ажилладаг бөгөөд энэ тохиолдолд бидний ашиг сонирхол бага зэрэг ялгаатай байдаг. Захиалагч төслийг төсөв, техникийн үзүүлэлтийн хүрээнд нарийн хардаг. Техникийн үзүүлэлтэд ороогүй янз бүрийн DevOps практикийн ашиг тусыг түүнд тайлбарлахад хэцүү байж болно. Хэрэв тэр бизнесийн нэмэлт үнэ цэнийг хурдан гаргах, эсвэл автоматжуулалтын шугам хоолой барих сонирхолтой байвал яах вэ?
Харамсалтай нь, урьдчилан батлагдсан зардлаар ажиллахад энэ сонирхол үргэлж олддоггүй. Манай практикт увайгүй, хайхрамжгүй гүйцэтгэгчийн хөгжлийг түүж авах тохиолдол гарч байсан. Энэ нь аймшигтай байсан: хамгийн сүүлийн үеийн эх код байхгүй, ижил системийн кодын суурь нь өөр өөр суулгацууд дээр өөр байсан, баримт бичиг нь хэсэгчлэн байхгүй, зарим талаараа аймшигтай чанартай байсан. Мэдээжийн хэрэг, үйлчлүүлэгч эх код, угсралт, хувилбаруудыг хянах эрхгүй байсан.
Одоогийн байдлаар хүн бүр DevOps-ийн талаар мэддэггүй ч бид түүний давуу тал, бодит нөөцийн хэмнэлтийн талаар ярихад бүх хэрэглэгчдийн нүд гэрэлтдэг. Тиймээс DevOps-ийг агуулсан хүсэлтийн тоо цаг хугацаа өнгөрөх тусам нэмэгдэж байна. Энд бид үйлчлүүлэгчидтэй ижил хэлээр хялбархан ярихын тулд бизнесийн асуудлууд болон DevOps-ийн практикийг хурдан холбох хэрэгтэй бөгөөд энэ нь тохирох хөгжлийн шугамыг бий болгоход туслах болно.
Тиймээс, бидэнд нэг талаасаа олон асуудал байгаа, нөгөө талаас DevOps-ийн мэдлэг, дадлага, хэрэгслүүд байна. Яагаад хүн бүртэй туршлагаа хуваалцаж болохгүй гэж?
DevOps бүтээгчийг бий болгох
Agile нь өөрийн гэсэн манифесттэй. ITIL нь өөрийн гэсэн аргачлалтай. DevOps нь тийм ч азгүй - загвар, стандартыг хараахан олж аваагүй байна. Хэдийгээр компаниудын хөгжил, үйл ажиллагааны туршлагын үнэлгээнд үндэслэн тэдгээрийн төлөвшлийг тодорхойлох.
Аз болоход, 2014 онд алдартай Gartner компани мөн DevOps-ийн гол практикууд болон тэдгээрийн хоорондын харилцаанд дүн шинжилгээ хийсэн. Үүний үндсэн дээр би инфографик гаргалаа.
Бид үүнийг үндэс болгон авсан . Дөрвөн бүс тус бүр нь багц хэрэгсэлтэй - бид тэдгээрийг мэдээллийн санд цуглуулж, хамгийн алдартайг нь тодорхойлж, нэгтгэх цэгүүд болон оновчтой оновчтой механизмуудыг тодорхойлсон. Нийтдээ энэ нь болсон 36 дадлага, 115 хэрэгсэл, дөрөвний нэг нь нээлттэй эх буюу үнэгүй програм хангамж юм. Дараа нь бид салбар тус бүрээр юунд хүрсэн, жишээ болгон энэ нийтлэлийг эхлүүлсэн техникийн баримт бичгийн менежментийг бий болгох төсөлд хэрхэн хэрэгжсэн тухай ярих болно.
Үйл явц
Алдарт EDMS төсөлд техникийн баримт бичгийн менежментийн системийг 10 объект тус бүр дээр ижил схемийн дагуу байрлуулсан. Суулгац нь өгөгдлийн сангийн сервер, програмын сервер, бүрэн текстийн индексжүүлэлт, агуулгын менежмент гэсэн 4 серверийг агуулдаг. Суурилуулалтын хувьд тэдгээр нь нэг зангилаа дотор ажилладаг бөгөөд байгууламжийн мэдээллийн төвд байрладаг. Бүх объектууд дэд бүтцийн хувьд бага зэрэг ялгаатай боловч энэ нь дэлхийн харилцан үйлчлэлд саад болохгүй.
Эхлээд DevOps практикийн дагуу бид дэд бүтцийг дотооддоо автоматжуулж, дараа нь туршилтын хэлхээнд, дараа нь хэрэглэгчийн бүтээгдэхүүн рүү хүргэлтийг авчирсан. Процесс бүрийг алхам алхмаар боловсруулсан. Хүрээлэн буй орчны тохиргоог эх кодын системд тохируулсан бөгөөд түгээлтийн иж бүрдлийг автоматаар шинэчлэх зорилгоор эмхэтгэсэн болно. Тохиргооны өөрчлөлт гарсан тохиолдолд инженерүүд зүгээр л хувилбарын хяналтын системд тохирох өөрчлөлтийг хийх хэрэгтэй бөгөөд дараа нь автомат шинэчлэлт нь асуудалгүй явагдах болно.
Энэхүү аргын ачаар туршилтын үйл явцыг ихээхэн хялбаршуулсан. Өмнө нь уг төсөлд стендүүдийг гараар шинэчлэхээс өөр зүйл хийдэггүй тестерүүд ажилладаг байсан. Одоо тэд зүгээр л ирж, бүх зүйл ажиллаж байгааг харж, илүү хэрэгтэй зүйл хийдэг. Шинэчлэлт бүрийг гадаргуугийн түвшингээс бизнесийн хувилбарын автоматжуулалт хүртэл автоматаар шалгадаг. Үр дүнг TestRail-д тусдаа тайлан болгон нийтэлсэн.
Соёл
Тасралтгүй туршилтыг туршилтын дизайны жишээгээр хамгийн сайн тайлбарладаг. Одоохондоо байхгүй байгаа системийг турших нь бүтээлч ажил юм. Туршилтын төлөвлөгөөг бичихдээ хэрхэн зөв тест хийх, аль салбарыг дагахыг ойлгох хэрэгтэй. Мөн шалгалтын оновчтой тоог тодорхойлохын тулд цаг хугацаа, төсвийн тэнцвэрийг олоорой. Шаардлагатай тестүүдийг яг сонгох, хэрэглэгч системтэй хэрхэн харьцах талаар бодох, хүрээлэн буй орчин, гадны хүчин зүйлсийг харгалзан үзэх нь чухал юм. Тасралтгүй туршилт хийхгүйгээр хийх боломжгүй юм.
Одоо харилцааны соёлын тухай. Өмнө нь инженер, хөгжүүлэгчид гэсэн хоёр эсрэг тал байсан. Хөгжүүлэгчид хэлэхдээ: "Бид үүнийг хэрхэн эхлүүлэх нь хамаагүй. Та бол инженер, та ухаалаг, энэ нь ямар ч доголдолгүй ажиллаж байгаа эсэхийг шалгаарай". Инженерүүд хариулав: "Та хөгжүүлэгчид хэтэрхий хайхрамжгүй байна. Илүү болгоомжтой байцгаая, тэгвэл бид таны хувилбаруудыг бага тоглох болно. Учир нь та бидэнд нууц код өгөх болгонд хэрхэн харилцах нь тодорхойгүй байна.". Энэ бол DevOps-ийн хэтийн төлөвөөс өөр бүтэцтэй соёлын харилцан үйлчлэлийн асуудал юм. Энд инженер, хөгжүүлэгчид хоёулаа байнга өөрчлөгдөж байдаг, гэхдээ нэгэн зэрэг найдвартай програм хангамж дээр төвлөрдөг нэг багийн нэг хэсэг юм.
Нэг багийн дотор мэргэжилтнүүд бие биедээ туслахаар шийдсэн. Өмнө нь байсан шигээ? Жишээ нь, 50 орчим хуудастай бүдүүн байршуулах заавар бэлтгэгдэж байсан.Инженер уншаад ямар нэг юм ойлгосонгүй, харааж зүхээд шөнийн гурван цагт хөгжүүлэгчээс тайлбар өгөхийг хүсэв. Хөгжүүлэгч тайлбар хийж, бас хараасан - эцэст нь хэн ч баярласангүй. Үүнээс гадна, мэдээжийн хэрэг, зарим алдаа байсан, учир нь та зааварт заасан бүх зүйлийг санаж чадахгүй. Одоо инженер нь хөгжүүлэгчийн хамт хэрэглээний програм хангамжийн дэд бүтцийг автоматаар байрлуулах скрипт бичиж байна. Мөн тэд бие биетэйгээ бараг ижил хэлээр ярьдаг.
хүн
Багийн хэмжээг шинэчлэлийн хамрах хүрээгээр тодорхойлно. Багийг хүргэх явцад элсүүлдэг бөгөөд үүнд төслийн ерөнхий багаас сонирхсон хүмүүс багтдаг. Дараа нь үе шат бүрийг хариуцах хүмүүстэй хамт шинэчлэлийн төлөвлөгөө бичиж, багийн ахиц дэвшлийг тайлагнадаг. Багийн бүх гишүүдийг сольж болно. Багийн нэг хэсэг болохын хувьд бид нөөц хөгжүүлэгчтэй ч бараг хэзээ ч холбогдох шаардлагагүй.
технологи
Технологийн диаграммд цөөн хэдэн зүйлийг онцлон тэмдэглэсэн боловч тэдгээрийн доор олон тооны технологи байдаг - та тэдгээрийн тайлбар бүхий бүхэл бүтэн ном хэвлэж болно. Тиймээс бид хамгийн сонирхолтой зүйлийг тодруулах болно.
Дэд бүтэц нь код
Одоо энэ үзэл баримтлал нь хэнийг ч гайхшруулахгүй байх магадлалтай, гэхдээ өмнө нь дэд бүтцийн тодорхойлолтыг хүссэн зүйлээ орхисон. , туршилтын орчин нь өвөрмөц байсан бөгөөд тэдгээрийг дээдэлж, нандигнаж, тоосны тоосонцорыг үлээж байв.
Өнөө үед хэн ч туршилт хийхээс айдаггүй. Виртуал машинуудын үндсэн зургууд, орчинг байрлуулахад бэлэн хувилбарууд байдаг. Бүх загвар, скриптүүд нь хувилбарын хяналтын системд хадгалагдаж, нэн даруй шинэчлэгддэг. Өмнө нь багцыг тавиур дээр хүргэх шаардлагатай үед тохиргооны цоорхой гарч ирэв. Одоо та зөвхөн эх код руу мөр нэмэх хэрэгтэй.
Дэд бүтцийн скриптүүд болон дамжуулах хоолойноос гадна Баримт бичгийг код болгон ашиглах аргыг баримтжуулахад ашигладаг. Үүний ачаар төсөлд шинэ хүмүүсийг холбох, жишээлбэл, туршилтын төлөвлөгөөнд тодорхойлсон функцууд дээр үндэслэн системд нэвтрүүлэх, мөн туршилтын тохиолдлуудыг дахин ашиглахад хялбар байдаг.
Тасралтгүй хүргэлт, хяналт
DevOps-ийн талаар бид тасралтгүй хүргэх, хянах хэрэгслийг хэрхэн сонгох талаар ярилцсан. Ихэнхдээ юу ч дахин бичих шаардлагагүй байдаг - өмнө нь бичсэн скриптүүдийг ашиглах, бүрэлдэхүүн хэсгүүдийн хооронд зөв уялдаа холбоог бий болгох, нийтлэг удирдлагын консол үүсгэхэд хангалттай. Бүх процессыг нэг товчлуур эсвэл хуваарийг ашиглан эхлүүлж болно.
Англи хэлэнд Continuous Delivery, Continuous Deployment гэсэн өөр өөр ойлголтууд байдаг. Хоёуланг нь "тасралтгүй хүргэлт" гэж орчуулж болох ч үнэндээ тэдгээрийн хооронд бага зэрэг ялгаа бий. Манай төсөлд түгээх эрчим хүчний компанийн техникийн баримт бичгийн урсгалын хувьд, харин Хүргэлтийг ашигладаг - командын дагуу үйлдвэрлэлийн суурилуулалт хийх үед. Байршуулах үед суулгалт автоматаар явагдана. Энэ төсөлд тасралтгүй хүргэлт ерөнхийдөө болсон DevOps-ийн төв хэсэг.
Ерөнхийдөө тодорхой параметрүүдийг цуглуулснаар DevOps практик яагаад хэрэгтэй болохыг тодорхой ойлгож чадна. Үүнийгээ тоонд үнэхээр дуртай удирдлагадаа уламжил. Нийт хөөргөх тоо, скриптийн үе шатуудын гүйцэтгэлийн хугацаа, амжилттай хөөргөлтийн эзлэх хувь - энэ бүхэн нь хүн бүрийн зах зээлд гарах дуртай цаг, өөрөөр хэлбэл хувилбарын хяналтын систем хүртэлх хугацаанаас эхлээд хувилбарыг гаргах хүртэлх хугацаанд шууд нөлөөлдөг. үйлдвэрлэлийн орчин. Шаардлагатай багаж хэрэгслийг хэрэгжүүлснээр инженерүүд үнэ цэнэтэй үзүүлэлтүүдийг шуудангаар хүлээн авдаг бөгөөд төслийн менежер тэдгээрийг хяналтын самбар дээр хардаг. Ингэснээр та шинэ хэрэгслийн ашиг тусыг нэн даруй үнэлж чадна. Мөн та DevOps дизайнерыг ашиглан тэдгээрийг дэд бүтцээрээ туршиж үзэх боломжтой.
Бидний хэнд хэрэгтэй вэ ?
Хуурамчлах хэрэггүй: эхлээд тэр бидэнд хэрэгтэй болсон. Өмнө дурьдсанчлан, та үйлчлүүлэгчтэй ижил хэлээр ярих хэрэгтэй бөгөөд DevOps дизайнерын тусламжтайгаар бид ийм ярианы үндэс суурийг хурдан гаргаж чадна. Бизнесийн мэргэжилтнүүд өөрт хэрэгтэй зүйлээ өөрсдөө үнэлж, улмаар илүү хурдан хөгжих боломжтой болно. Бид загвар зохион бүтээгчийг аль болох нарийвчлан гаргахыг хичээсэн бөгөөд ямар ч хэрэглэгч юу сонгож байгаагаа ойлгохын тулд олон тайлбарыг нэмж оруулсан.
Дизайнерын формат нь барилгын үйл явц, автоматжуулалтын чиглэлээр компанийн одоо байгаа хөгжлийг харгалзан үзэх боломжийг олгодог. Хэрэв та зөвхөн одоо байгаа үйл явцтай сайн уялдаж, хоосон зайг нөхөж чадах шийдлүүдийг сонгож чадвал бүх зүйлийг нурааж, дахин босгох шаардлагагүй болно.
Магадгүй таны хөгжил аль хэдийн илүү өндөр түвшинд шилжсэн бөгөөд бидний хэрэгсэл хэтэрхий "ахмад" мэт санагдаж магадгүй юм. Гэхдээ бид өөрсдөдөө хэрэгтэй гэж бодож байгаа бөгөөд зарим уншигчдад хэрэг болно гэж найдаж байна. Бид танд сануулж байна дизайнер руу - хэрэв ямар нэгэн зүйл байвал та анхны өгөгдлийг оруулсны дараа диаграммыг шууд хүлээн авна. Бид таны санал хүсэлт, нэмэлт өөрчлөлтөд талархах болно.
Эх сурвалж: www.habr.com