DevOps-ийн тухай ярихдаа гол санааг ойлгоход хэцүү байна уу? Мэргэжилтэн бус хүмүүст ч гэсэн зорилгодоо хүрэхэд туслах тод аналоги, гайхалтай томъёолол, мэргэжилтнүүдийн зөвлөгөөг бид танд зориулж цуглуулсан. Эцэст нь урамшуулал нь Red Hat-ийн ажилчдын өөрсдийн DevOps юм.
DevOps гэдэг нэр томъёо нь 10 жилийн өмнө үүссэн бөгөөд Twitter hashtag-аас Мэдээллийн технологийн ертөнц дэх хүчирхэг соёлын хөдөлгөөн болж хувирсан бөгөөд хөгжүүлэгчид аливаа зүйлийг илүү хурдан хийж, туршилт хийж, давтахыг дэмждэг жинхэнэ философи болжээ. DevOps нь дижитал өөрчлөлтийн үзэл баримтлалтай салшгүй холбоотой болсон. Гэхдээ МТ-ийн нэр томьёонд байнга тохиолддог шиг, сүүлийн арван жилийн хугацаанд DevOps өөрийн тухай олон тодорхойлолт, тайлбар, буруу ойлголтыг олж авсан.
Тиймээс та DevOps-ийн талаар олон удаа асуулт сонсож болно, энэ нь agile-тэй ижил үү? Эсвэл энэ нь тусгай аргачлал уу? Эсвэл энэ нь "хамтын ажиллагаа" гэсэн үгний өөр нэг ижил утгатай юу?
DevOps нь олон янзын ойлголтуудыг (тасралтгүй хүргэлт, тасралтгүй нэгтгэх, автоматжуулалт гэх мэт) агуулдаг тул чухал зүйлийг нэрлэх нь ялангуяа тухайн сэдвийг сонирхож байгаа үед хэцүү байж болно. Гэсэн хэдий ч, энэ чадвар нь та өөрийн санаагаа дарга нартаа хүргэх гэж оролдсон эсвэл гэр бүл, найз нөхдөөсөө хэн нэгэнд ажлынхаа талаар хэлэхээс үл хамааран маш хэрэгтэй. Тиймээс одоохондоо DevOps-ийн нэр томьёоны нарийн ширийн зүйлийг хойш тавьж, том зураг дээр анхаарлаа хандуулцгаая.
DevOps гэж юу вэ: 6 тодорхойлолт ба аналоги
Бид мэргэжилтнүүдээс DevOps-ийн мөн чанарыг аль болох энгийн бөгөөд товч тайлбарлахыг хүссэн бөгөөд ингэснээр түүний үнэ цэнэ нь ямар ч түвшний техникийн мэдлэгтэй уншигчдад ойлгомжтой болно. Эдгээр харилцан ярианы үр дүнд үндэслэн бид танд DevOps-ийн тухай түүхийг бүтээхэд туслах хамгийн гайхалтай аналоги, гайхалтай томъёоллыг сонгосон.
1. DevOps бол соёлын хөдөлгөөн юм
"DevOps бол хоёр тал (програм хангамж хөгжүүлэгчид болон мэдээллийн технологийн системийн үйл ажиллагааны мэргэжилтнүүд) хэн нэгэн ашиглаж эхлэх хүртэл програм хангамж нь бодит ашиг тус авчрахгүй гэдгийг хүлээн зөвшөөрдөг соёлын хөдөлгөөн юм: гол нь хэрэглэгчид, үйлчлүүлэгчид, ажилчид, харин гол зүйл биш" гэж ахлах судлаач Эвелин Оерлих хэлэв. DevOps хүрээлэнгийн шинжээч. "Тиймээс эдгээр хоёр тал хамтран програм хангамжийг хурдан бөгөөд чанартай хүргэхийг баталгаажуулдаг."
2. DevOps бол хөгжүүлэгчдийг чадавхжуулах явдал юм.
"DevOps нь хөгжүүлэгчдэд програмуудыг эзэмших, ажиллуулах, хүргэлтийг эхнээс нь дуустал удирдах боломжийг олгодог."
Liberty Mutual даатгалын компанийн DevOps платформын захирал Жай Шниепп "Ерөнхийдөө DevOps нь автоматжуулсан процессыг бий болгож, хэрэгжүүлэх замаар үйлдвэрлэлд програм хангамжийг хүргэхийг хурдасгах арга зам гэж ярьдаг." "Гэхдээ миний хувьд энэ нь илүү чухал зүйл юм." DevOps нь хөгжүүлэгчдэд програм эсвэл тодорхой програм хангамжийг эзэмшиж, тэдгээрийг ажиллуулж, эхнээс нь дуустал хүргэх боломжийг олгодог. DevOps нь хариуцлагын төөрөгдлийг арилгаж, автоматжуулсан, хөгжүүлэгчд суурилсан дэд бүтцийг бий болгоход оролцож буй бүх хүмүүст чиглүүлдэг."
3. DevOps нь аппликейшн үүсгэх, хүргэхэд хамтран ажиллах тухай юм.
"Энгийнээр хэлбэл, DevOps бол хүн бүр хамтран ажилладаг програм хангамж үйлдвэрлэх, хүргэх арга юм" гэж BMC-ийн дижитал бизнесийн автоматжуулалт хариуцсан ерөнхийлөгч, дарга Гур Стаф хэлэв.
4. DevOps бол дамжуулах хоолой юм
"Бүх эд анги нь хоорондоо таарч байвал конвейер угсрах боломжтой."
"Би DevOps-ийг машин угсрах шугамтай зүйрлэх болно" гэж Гурын ажилтан үргэлжлүүлэн хэлэв. – Бүх эд ангиудыг бие даан тохируулахгүйгээр угсарч болохуйцаар урьдчилж загварчлах, хийх санаа юм. Конвейерийн угсралт нь зөвхөн бүх эд ангиуд нь хоорондоо таарч байвал боломжтой. Хөдөлгүүрийг зохион бүтээж, бүтээж буй хүмүүс үүнийг их бие эсвэл хүрээ рүү хэрхэн холбох талаар бодох ёстой. Тоормос хийдэг хүмүүс дугуй гэх мэтийг бодох ёстой. Програм хангамжийн хувьд ч мөн адил байх ёстой.
Бизнесийн логик эсвэл хэрэглэгчийн интерфэйсийг бий болгож буй хөгжүүлэгч нь хэрэглэгчийн мэдээллийг хадгалдаг мэдээллийн сан, хэрэглэгчийн мэдээллийг хамгаалах аюулгүй байдлын арга хэмжээ, үйлчилгээ нь том, магадгүй бүр олон сая долларын хэрэглэгчдэд үйлчилж эхлэхэд энэ бүхэн хэрхэн ажиллах талаар бодох ёстой. ."
“Хүмүүсийг зөвхөн өөрсдийнхөө ажилд анхаарлаа төвлөрүүлэхээс илүүтэй хамтран ажиллаж, бусад хүмүүсийн хийж байгаа ажлын талаар бодоход хүргэх нь даван туулах хамгийн том саад бэрхшээл юм. Хэрэв та үүнийг хийж чадвал дижитал өөрчлөлт хийх маш сайн боломж байна" гэж Гур Стафф нэмж хэлэв.
5. DevOps бол хүмүүс, үйл явц, автоматжуулалтын зөв хослол юм
DevOps хүрээлэнгийн гүйцэтгэх захирал Жейн Гролл DevOps-ийг тайлбарлах гайхалтай зүйрлэлийг санал болгов. Түүний хэлснээр, "DevOps нь хүмүүс, процесс, автоматжуулалт гэсэн гурван үндсэн орц найрлагатай жортой адил юм. Эдгээр орцуудын ихэнхийг бусад салбар, эх сурвалжаас авч болно: Lean, Agile, SRE, CI/CD, ITIL, манлайлал, соёл, багаж хэрэгсэл. Ямар ч сайн жорын нэгэн адил DevOps-ийн нууц нь програмуудыг үүсгэх, гаргах хурд, үр ашгийг нэмэгдүүлэхийн тулд эдгээр найрлагыг хэрхэн зөв харьцаа, холих вэ гэдэгт оршино."
6. DevOps бол програмистууд Формула 1-ийн баг шиг ажилладаг
"Уралдаанд эхнээсээ барианд төлөвлөгддөггүй, харин эсрэгээр, барианд орох хүртэл."
Red Hat-ийн үүлэн платформын маркетингийн ахлах менежер, DevOps'ish мэдээллийн товхимолыг нийтлэгч Крис Шорт хэлэхдээ "Би DevOps санаачлагаас юу хүлээж болох талаар ярихдаа NASCAR эсвэл Формула 1 уралдааны багийг жишээ болгон боддог" гэж хэлэв. – Ийм багийн ахлагч нэг зорилготой байдаг: уралдааны төгсгөлд багт байгаа нөөц бололцоо, түүнд тулгарч буй бэрхшээлийг харгалзан хамгийн өндөр байрыг эзлэх. Энэ тохиолдолд уралдааныг эхнээс нь дуустал биш, харин эсрэгээр, барианд орох хүртэл төлөвлөдөг. Эхлээд амбицтай зорилго тавьж, дараа нь түүнд хүрэх арга замыг тодорхойлно. Дараа нь тэдгээрийг дэд ажлуудад хувааж, багийн гишүүдэд хуваарилдаг."
“Тэмцээний өмнөх бүтэн долоо хоногийг баг нь пит-стопыг төгс болгоход зарцуулдаг. Тэр хүнд хэцүү уралдааны өдөр формоо хадгалахын тулд хүч чадлын бэлтгэл, кардио дасгал хийдэг. Тэмцээний үеэр гарч болох аливаа асуудлыг шийдвэрлэхийн тулд хамтран ажиллах дадлага хийдэг. Үүний нэгэн адил хөгжүүлэлтийн баг шинэ хувилбаруудыг байнга гаргах ур чадварыг сургах ёстой. Хэрэв танд ийм ур чадвар, сайн ажилладаг хамгаалалтын систем байгаа бол шинэ хувилбаруудыг үйлдвэрлэлд нэвтрүүлэх нь илүү олон удаа тохиолддог. Энэ ертөнцийг үзэх үзэлд хурд нэмэгдэх нь аюулгүй байдлыг нэмэгдүүлнэ гэсэн үг” гэж Шорт хэлэв.
"Энэ нь" зөв зүйл " хийх тухай биш" гэж Шорт нэмж хэлэв "энэ нь хүссэн үр дүнд хүрэх замд саад болж буй аль болох олон зүйлийг арилгах явдал юм. Бодит цаг хугацаанд хүлээн авсан санал хүсэлтдээ үндэслэн хамтран ажиллаж, дасан зохицоорой. Зорилгодоо хүрэх ахиц дэвшилд үзүүлэх нөлөөллийг багасгахын тулд гажуудалд бэлэн байж, чанарыг сайжруулахын төлөө ажиллана уу. Энэ бол DevOps ертөнцөд биднийг хүлээж буй зүйл юм."
DevOps-ийг хэрхэн томруулах вэ: Мэргэжилтнүүдийн 10 зөвлөмж
Зүгээр л DevOps болон масс DevOps бол огт өөр зүйл юм. Эхнийхээс хоёр дахь хүртэлх замд саад бэрхшээлийг хэрхэн даван туулах талаар бид танд хэлэх болно.
Олон байгууллагын хувьд DevOps руу хийх аялал хялбар бөгөөд тааламжтай эхэлдэг. Жижигхэн хүсэл тэмүүлэлтэй багууд бий болж, хуучин үйл явц нь шинээр солигдож, анхны амжилтууд удахгүй гарахгүй.
Харамсалтай нь, энэ бол зүгээр л хуурамч гялбаа, ахиц дэвшлийн хуурмаг зүйл гэж North Highland зөвлөхийн дижитал хэлтсийн дарга, удирдагч Бен Гриннелл хэлэв. Эрт ялалтууд нь мэдээж урам зоригтой боловч DevOps-ийг байгууллага даяар өргөнөөр нэвтрүүлэх эцсийн зорилгод хүрэхэд тус болохгүй.
Үүний үр дүнд “бид” болон “тэд” гэж хуваагдах соёл бий болсон нь ойлгомжтой.
"Ихэнхдээ байгууллагууд гол төлөв DevOps-ийн замыг засна гэж бодож эдгээр анхдагч төслүүдийг эхлүүлдэг бөгөөд бусад хүмүүс энэ замыг дагаж чадах эсэх, хүсэл эрмэлзэл байх эсэхээс үл хамааран" гэж Бен Гриннелл тайлбарлав. – Ийм төслүүдийг хэрэгжүүлэх багийг ихэвчлэн өөр газар үүнтэй төстэй зүйл хийж байсан ч танай байгууллагад шинээр орж ирсэн өөртөө итгэлтэй “Варангчууд”-аас авдаг. Үүний зэрэгцээ, бусад бүх хүмүүст заавал дагаж мөрдөх дүрмийг зөрчиж, устгахыг уриалж байна. Үүний үр дүнд мэдлэг, ур чадварын шилжилт хөдөлгөөнд саад болох “бид”, “тэд” хоёрын соёл бий болж байгааг ойлгоход хялбар байдаг” гэж хэлжээ.
"Энэ соёлын асуудал бол DevOps-ийг өргөжүүлэхэд хэцүү байгаа шалтгаануудын нэг юм. DevOps-ын багууд хурдацтай хөгжиж буй мэдээллийн технологийн анхны компаниудад тохиолддог техникийн сорилтуудтай тулгарч байна" гэж Scalyr-ийн үүсгэн байгуулагч, ТУЗ-ийн дарга Стив Ньюман хэлэв.
“Орчин үеийн ертөнцөд үйлчилгээ хэрэгцээ гармагц өөрчлөгддөг. Шинэ боломжуудыг байнга хэрэгжүүлж, хэрэгжүүлэх нь гайхалтай боловч энэ үйл явцыг зохицуулж, үүссэн асуудлуудыг арилгах нь жинхэнэ толгойн өвчин юм гэж Стив Ньюман нэмж хэлэв. – Маш хурдацтай хөгжиж буй байгууллагуудад харилцан үйлчлэлийн багуудын инженерүүд өөрчлөлт болон үүнээс үүдэн бий болгож буй хамаарлын түвшний каскадын нөлөөллийн харагдах байдлыг хадгалахын төлөө тэмцдэг. Түүгээр ч барахгүй инженерүүд энэ боломжоо алдсандаа баярлахгүй, улмаар үүсч буй асуудлын мөн чанарыг ойлгоход хэцүү болж байна” гэв.
Дээр дурдсан эдгээр сорилтуудыг хэрхэн даван туулж, DevOps-ийг томоохон байгууллагад хэрхэн нэвтрүүлэх вэ? Мэргэжилтнүүд таны эцсийн зорилго бол програм хангамж хөгжүүлэх мөчлөг, бизнесийн үйл явцыг хурдасгах байсан ч тэвчээртэй байхыг уриалж байна.
1. Соёлыг өөрчлөхөд цаг хугацаа хэрэгтэй гэдгийг санаарай.
Жейн Гролл, DevOps хүрээлэнгийн гүйцэтгэх захирал: "Миний бодлоор DevOps-ийн өргөтгөл нь хурдны хөгжил (мөн соёлыг ч мөн адил хөндөх) шиг үе шаттай, давтагдах ёстой. Agile болон DevOps нь жижиг багийг онцолдог. Гэвч эдгээр багуудын тоо нэмэгдэж, нэгдэхийн хэрээр бид илүү олон хүмүүс ажлын шинэ арга барилыг нэвтрүүлж, үүний үр дүнд соёлын асар их өөрчлөлт гарч байна."
2. Төлөвлөлт хийх, платформ сонгоход хангалттай цаг зарцуул
Эран Кинсбрунер, Perfecto-ийн Техникийн ахлах евангелист: “Ажиллах хэмжээнд хүрэхийн тулд DevOps багууд эхлээд уламжлалт процесс, багаж хэрэгсэл, ур чадвараа хослуулж сурах ёстой бөгөөд дараа нь DevOps-ын үе шат бүрийг аажмаар хөгжүүлж, тогтворжуулах хэрэгтэй. Энэ бүхэн нь хэрэглэгчийн түүх, үнэ цэнийн урсгалыг сайтар төлөвлөхөөс эхэлдэг бөгөөд дараа нь trunk-д суурилсан хөгжүүлэлт эсвэл кодыг салбарлах, нэгтгэхэд хамгийн тохиромжтой бусад аргыг ашиглан програм хангамж, хувилбарын хяналтыг бичихээс эхэлдэг."
"Дараа нь автоматжуулалтын өргөтгөх боломжтой платформ шаардлагатай байгаа интеграци, туршилтын үе шат ирдэг. Энэ бол DevOps багуудын ур чадварын түвшин болон төслийн эцсийн зорилгод тохирсон зөв платформыг сонгох нь чухал юм.
Дараагийн үе шат бол үйлдвэрлэлд нэвтрүүлэх бөгөөд үүнийг зохион байгуулах хэрэгсэл, контейнер ашиглан бүрэн автоматжуулах ёстой. DevOps-ийн бүх үе шатанд виртуалчлагдсан орчин (үйлдвэрлэлийн симулятор, QA орчин, бодит үйлдвэрлэлийн орчин) байх нь чухал бөгөөд холбогдох дүгнэлтийг гаргахын тулд туршилтанд зөвхөн хамгийн сүүлийн үеийн өгөгдлийг ашиглах нь чухал юм. Аналитик нь ухаалаг байх ёстой бөгөөд хурдан бөгөөд үр дүнтэй санал хүсэлт бүхий том өгөгдлийг боловсруулах чадвартай байх ёстой."
3. Гэм бурууг хариуцлагаас ав.
Гордон Хафф, RedHat Evangelist: “Туршилт хийх боломжийг олгох, дэмжих систем, уур амьсгалыг бий болгох нь Agile програм хангамжийг хөгжүүлэхэд амжилтгүй болох боломжтой. Энэ нь бүтэлгүйтэлд өөр хэн ч хариуцлага хүлээхгүй гэсэн үг биш юм. Үнэн хэрэгтээ, "хариуцлагатай байх" нь "осол гаргах" гэсэн үг биш тул хэн хариуцлага хүлээхийг тодорхойлох нь бүр ч хялбар болно. Хариуцлагын мөн чанар нь чанарын хувьд өөрчлөгддөг гэсэн үг. Дөрвөн хүчин зүйл чухал болж байна: тасалдал, арга барил, үйлдвэрлэлийн үйл явц, урамшуулал." (Та эдгээр хүчин зүйлсийн талаар Гордон Хаффын “DevOps хичээлүүд: Эрүүл туршилтын 4 тал” нийтлэлээс уншиж болно.)
4. Урагшлах замыг арилга
Бен Гриннелл, North Highland зөвлөх компанийн дижитал хэлтсийн дарга, менежер: "Хамшралд хүрэхийн тулд би анхдагч төслүүдтэй хамт "зам цэвэрлэх" хөтөлбөрийг эхлүүлэхийг зөвлөж байна. Энэхүү хөтөлбөрийн зорилго нь DevOps-ийн анхдагчид хоцрогдсон дүрэм журам гэх мэт хог хаягдлыг цэвэрлэж, цаашдын зам нь тодорхой хэвээр байх болно."
“Ажиллах шинэ арга барилын амжилтыг өргөнөөр тэмдэглэх замаар анхдагч бүлгээс давсан харилцаа холбоогоор дамжуулан хүмүүст зохион байгуулалтын дэмжлэг, эрч хүч өг. DevOps төслүүдийн дараагийн давалгаанд хамрагдаж, DevOps-ийг анх удаа ашиглахдаа сандарч буй хүмүүсийг сурга. Мөн эдгээр хүмүүс анхдагчдаас тэс өөр гэдгийг санаарай."
5. Ардчиллын хэрэгсэл
Стив Ньюман, Scalyr-ийн үүсгэн байгуулагч, дарга: “Хэрэгслүүд нь хүмүүсээс нуугдаж болохгүй бөгөөд цаг зав гаргах хүсэлтэй хэн бүхэнд сурахад харьцангуй хялбар байх ёстой. Бүртгэлээс лавлагаа авах чадвар нь багажийг ашиглах "баталгаажсан" гурван хүнээр хязгаарлагддаг бол танд маш том тооцоолох орчинтой байсан ч асуудлыг шийдвэрлэх хамгийн ихдээ гурван хүн байх болно. Өөрөөр хэлбэл, ноцтой (бизнесийн) үр дагаварт хүргэж болзошгүй гацаа энд байна."
6. Багаар ажиллах хамгийн тохиромжтой нөхцлийг бүрдүүлнэ
Том Кларк, ITV-ийн нийтлэг платформын дарга: "Чи юуг ч хийж чадна, гэхдээ бүгдийг нэг дор хийж чадахгүй. Тиймээс том зорилго тавьж, багаас эхэлж, хурдацтай давталтаар урагшил. Цаг хугацаа өнгөрөх тусам та ажлаа амжуулах нэр хүндтэй болох тул бусад хүмүүс ч бас таны аргыг ашиглахыг хүсэх болно. Мөн өндөр үр дүнтэй баг бүрдүүлэх талаар санаа зовох хэрэггүй. Үүний оронд хүмүүсийг ажиллах таатай нөхцөлөөр хангаж өгвөл үр ашигтай ажиллах болно."
7. Конвейгийн хууль болон Канбаны самбаруудын талаар бүү мартаарай
Logan Daigle, CollabNetVersionOne-ийн Програм хангамжийн хүргэлт ба DevOps стратегийн захирал: “Конвейн хуулийн үр дагаврыг ойлгох нь чухал. Миний задруулсан хэллэгээр, энэ хуульд бидний бий болгож буй бүтээгдэхүүн, үүнд ашигладаг үйл явц, тэр дундаа DevOps нь манай байгууллагатай ижил бүтэцтэй болохыг харуулж байна."
“Байгууллагад олон тооны силос байгаа бөгөөд хяналтыг төлөвлөх, бүтээх, програм хангамжийг гаргахдаа олон удаа сольдог бол масштабын үр нөлөө тэг эсвэл богино хугацаанд байх болно. Хэрэв байгууллага зах зээлд чиглэсэн санхүүжилттэй бүтээгдэхүүнүүдийн эргэн тойронд олон талт үйл ажиллагааны баг бүрдүүлбэл амжилтанд хүрэх магадлал эрс нэмэгддэг."
"Өршөөлтийн өөр нэг чухал тал бол хийгдэж буй бүх ажлыг (WIP, ажлын явц) Канбан самбар дээр харуулах явдал юм. Байгууллага хүмүүст эдгээр зүйлийг харах боломжтой газар байвал энэ нь хамтын ажиллагааг ихээхэн дэмждэг бөгөөд энэ нь цар хүрээг нэмэгдүүлэхэд эерэг нөлөө үзүүлдэг."
8. Хуучин сорвийг хайж олох
Manuel Pais, DevOps зөвлөх, Team Topologies-ийн хамтран зохиогч: “DevOps-ын дадлага туршлагыг Dev болон Ops-ээс өөр авч, бусад функцүүдэд ашиглахыг оролдох нь оновчтой арга биш юм. Энэ нь мэдээжийн хэрэг тодорхой хэмжээгээр нөлөөлнө (жишээ нь, гарын авлагын удирдлагыг автоматжуулах гэх мэт), гэхдээ бид хүргэх болон санал хүсэлтийн үйл явцыг ойлгож эхэлбэл илүү их үр дүнд хүрч чадна."
"Хэрэв байгууллагын мэдээллийн технологийн системд хуучин сорви байгаа бол - өмнөх ослын үр дүнд хэрэгжиж байсан журам, удирдлагын механизмууд, гэхдээ ач холбогдолоо алдсан (бүтээгдэхүүн, технологи, үйл явцын өөрчлөлтийн улмаас) - тэдгээрийг арилгах хэрэгтэй. эсвэл үр ашиггүй эсвэл шаардлагагүй үйл явцыг автоматжуулахын оронд жигдрүүлсэн."
9. DevOps хувилбаруудыг бүү хөгжүүл
Энтони Эдвардс, Eggplant компанийн үйл ажиллагааны захирал: "DevOps бол маш тодорхой бус нэр томъёо тул баг бүр өөрийн гэсэн DevOps хувилбартай байдаг. Байгууллага гэнэт 20 төрлийн DevOps-той болвол тийм ч муу зүйл байхгүй. Гурван хөгжүүлэлтийн баг бүр хөгжүүлэлт ба бүтээгдэхүүний менежментийн хооронд өөрийн гэсэн тусгай интерфейстэй байх боломжгүй юм. Бүтээгдэхүүнийг үйлдвэрлэлийн симулятор руу шилжүүлэх үед санал хүсэлтийг боловсруулах өөрийн гэсэн өвөрмөц хүлээлттэй байх ёсгүй. Үгүй бол та DevOps-ийг хэзээ ч өргөжүүлж чадахгүй."
10. DevOps-ийн бизнесийн үнэ цэнийг номло
Стив Ньюман, Scalyr-ийн үүсгэн байгуулагч, дарга: “DevOps-ийн үнэ цэнийг таньж мэдэхийн тулд ажилла. Хийж байгаа зүйлийнхээ ашиг тусын талаар чөлөөтэй ярьж сур. DevOps бол цаг хугацаа, мөнгө хэмнэх гайхалтай хэрэгсэл юм (зүгээр л бодоод үз: сул зогсолт багасч, нөхөн сэргээх дундаж хугацаа богино байна) бөгөөд DevOps-ийн багууд бизнесийн амжилтад хүрэх эдгээр санаачлагуудын ач холбогдлыг уйгагүй онцолж (мөн номлох) ёстой. Ингэснээр та дэмжигчдийн хүрээг тэлж, байгууллага дахь DevOps-ийн нөлөөг нэмэгдүүлэх боломжтой."
БОНУС
дээр Манай DevOps 13-р сарын XNUMX-нд ирнэ - тийм ээ, Red Hat програм хангамж үйлдвэрлэгчийн хувьд өөрийн гэсэн DevOps баг, дадлага туршлагатай.
Байгууллагын бусад бүлгүүдэд зориулсан дотоод автоматжуулалтын үйлчилгээг хөгжүүлдэг манай инженер Марк Биргер өөрийн түүхийг орос хэлээр тодорхой өгүүлэх болно - Red Hat DevOps баг Ansible-ийн удирддаг Hat Virtualization виртуал орчноос программуудыг бүрэн хэмжээний контейнер формат руу хэрхэн шилжүүлсэн тухай OpenShift платформ.
Гэхдээ энэ нь бүгд биш:
Байгууллагууд ажлын ачааллыг контейнерт шилжүүлсний дараа хэрэглээний хяналтын уламжлалт аргууд ажиллахгүй байж магадгүй юм. Хоёрдахь илтгэлээр бид бүртгэлийн арга барилаа өөрчлөх сэдлийг тайлбарлаж, орчин үеийн мод бэлтгэх, хянах арга руу хөтөлсөн замын үргэлжлэлийг харуулах болно.
Эх сурвалж: www.habr.com