DevOps-н хөгжил-хувьсал
Програм хангамжийн хөгжүүлэлт (dev: development), засвар үйлчилгээ (ops: operations) анх ямар байсан, хаашаа чиглэж байгааг хамтдаа сонирхъё.
1940-өөд он
Анхны цахим компьютерийг зөвхөн математик тооцооллын зорилгоор ашигладаг байжээ. Ингэхдээ компьютерийг машины хэл буюу 0, 1-н цуваагаар програмчилдаг байлаа. Тогтооход бэрх байсан тул комманд бүрт харгалзах 0, 1 -н цуваанд нэр оноож, түүнийгээ мнемоник код гэж нэрийдэв. Мнемоник кодын хүснэгтийг ашиглаж програмчилдаг байсанаа, яваандаа энэ хүснэгтээс санаа авч ассемблер хэлийг зохиожээ.
Удалгүй хэд хэдэн дээд түвшиний програмчлалын хэл зохиогдсон боловч ажиллах бүртээ машины хэл рүү хөрвүүлэгддэг байсан тул машины хэл дээр бичсэн програмаас удаан байлаа. Compiler (алдаа илрүүлэгч) байхгүй болохоор алдаагаа хянахад хамаг цагаа бардаг байжээ. Энэ үед operations гэдэг юм байсангүй. Програмаа ажиллууллаа. Үр дүнгээ авлаа. Боллоо. Зөвхөн нэг удаагийн зорилгоор ашигладаг байжээ.
1950, 1960-аад он
Дээд түвшиний програмчлалын хэл олноор бий болсон ч програмаа хадгалах, ажиллуулахын тулд нүхэлсэн цаас ашигласаар л байв. Засвар оруулсаны дараа дахин нүхэлж, програмаа ажиллуулдаг байв. Програмчлах, тестлэх ажилллагаа өртөг ихтэй байсанаас эхлээд сайтар бодох (шинжилгээ зохиомжид илүү их хугацаа зарцуулах) шаардлагатай байлаа.
Шийдвэрлэх асуудал нь нэг хариутай, тун энгийн оролт (өгөгдсөн нь), гаралт (олох нь)-тай. Бүгдийг урьдчилан төлөвлөх боломж өндөр. Бараг л математикийн бодлого бодохоос өөрцгүй байжээ. Энэ байдал нь шугаман буюу Waterfall загвар үүсэх гол шалтгаан болсон бололтой. Өмнөх үеийг бодвол хөгжүүлэх ажиллагаанд дэвшил гарсан ч компьютерийн хэрэглээ судлагааны байгууллагаас хэтэрсэнгүй. Зөвхөн тооцоо хийхэд ашиглаж байсан тул орчин үеийн operations-н тухай ойлголт байсангүй.
NASA хүртэл компьютерийн оронд хүн ашигладаг (математикчид гар аргаар тооцоо хийдэг) байв. Компьютер ашиглаж чадах мэргэжилтэн ч ховор байж. Энэ тухай Hidden Figures киноноос үзэж болно.
Мэинфрэим компьютерийг ажиллуулах нь нэн төвөгтэй, тусгай мэргэшсэн-тенхикч л хийдэг ажил, дэлгэц гэж байсангүй онгоц шиг хяналтын самбар гэж юм байв.
1970-аад он
1970-аад оноос нүхэлсэн цаасны оронд соронзон тууз ашиглах болжээ. Өмнө нь хяналтын дэлгэцгүй байсан бол дэлгэцтэй болж, бичиж байх явцдаа програмын кодыг хянах, засах боломжтой болсон байна. Ингэж нэг юм хөгжүүлэлт, тест 2-г нэг компьютер дээр хийх боломж олдов.
Компьютерийн хэрэглээ судлагааны байгууллагаас хальж хувийн хэвшил рүү нэвтрэв. Гэхдээ нягтлан бодох бүртгэл, цалин, төлбөрийн нэхэмжлэх, санхүүгийн тайлан гаргах төдийхөнөөр хязгаарлагдаж байж. Компьютерийг жирийн нэгэн худалдан авч хүчрэхгүй, мэдээллийн системийг зөвхөн пүүс компаниуд дотоод хэрэгцээндээ ашигладаг байв.
1980-аад он
Персональ компьютер бий болж, тооцооллын хүчин чадал нь нэмэгдэж, өртөг хямдарсанаар бусад салбар руу эрчимтэй нэвтрэх болов. Гэсэн хэдий ч өнөөгийн бидний хэрэглэдэг цахим системийг бодвол тийм ч нарийн төвөгтэй биш, өөрчлөгдөх давтамж нь бага байсан учраас бүгдийг нэг удаа, анхнаас нь алдаагүй бодож, гүйцэтгэж болно гэж итгэдэг байлаа.
Бүгдийг нэг удаа төлөвлөдөг байсанаас хугацаа өнгөрөх тусам өөрчлөлт оруулах нь эрсдэл дагуулахаас гадна өртөг өндөрснө гэдэг үзэл ноёрхож байв. Мөн релийз хоорондох хугацаа хол, зах зээлийн өрсөлдөөн ч байхгүй шахам байлаа. Зөвхөн нэг удаа хөгжүүлээд хаядаг, эсвэл дараачийн хувилбарыг хийж эхэлтэл/дуустал нэлээд хэдэн жил хүлээдэг байжээ.
Бүгдийг нэг удаа тооцдог арга хоцрогдож өөр дэвшилтэт арга эрэлхийлэх болов. Бүхнийг эхнээс нь нэг амьсгаагаар зөв хийхийн тулд нэг бүрчлэн судлах, үүнд ихээхэн хугацаа зарцуулах шаардлагатай. Гэтэл тэр хооронд өмнө нь хэрэгтэй гэж үзэж байсан функц үнэ цэнээ алдах, цаг үеийн шаардлагаар өөрчлөгдчихнө. Мөн захиалагч болон гүйцэтгэгч талын системийн тухай мэдлэг гүнзгийрэхийн хэрээр хэрэгцээ шаардлага өөрчлөгднө. Харамсалтай нь системийн талаарх зөв төсөөлөл бий болохын тулд суралцах хугацаа заавал хэрэгтэй ажээ. Энэ үеэс спирал, инкрементал загвар буюу олон жижиг хүрхрээг дараалан үйлдэх гэсэн санаанууд гарч ирэв.
Спирал загварын хөгжүүлэлт: Эрсдлийг эрт илрүүлэх, зөв төсөөлөлтэй болохын тулд прототаип гээчийг хийх болжээ. Прототаип гэдэг нь төсөлд оролцогч талууд (хэрэглэгч болон хөгжүүлэгч) ирээдүйд бий болох системийн талаарх ойлголтоо нэгтгэх зорилгоор туршилтын жижиг хувилбарыг хөгжүүлж, хэрэглэгчийн саналыг тусгах замаар системийг сайжруулах арга хэлбэрийг хэлнэ. Хөгжүүлэлт давталттай хэлбэрээр өрнөнө.
Инкрементал хөгжүүлэлт: Өсөлттэй-хэсэгчилэн хөгжүүлэх арга. Хөгжүүлэлтийг фазуудад хувааж, фаз бүрт өөр боломж нэмэх, өмнөх үр дүнд тулгуурлаж дараачийн хэсгийг нийлүүлж угсарна. 1980-аад онд эрчимтэй хөгжиж эхэлсэн. Анхны оролдлогууд 1957 онд IBM, 1960-аад онд NASA дээр хийгдэж байсан баримт буй.
1990-ээд оноос
Энэ үеэс эхлээд бизнесийн өрсөлдөөн ширүүсч, хугацааны эхэнд хэрэгтэй гэж үзэж байсан функц хэрэггүй болох, эсвэл өөрчлөгдөх болж, захиалагч хөгжүүлэгч хоёрын хооронд үл ойлголцол үүсэх болов.
Цахим системийн хэрэглээ ихэссэнээр системийн ачаалал ихэсч багасах, системийн ажиллагааг хянах, доголдолгүй ажиллагааг хангах шаардлага бий болов. Энэ үеэс жинхэнэ утгаар operations гэдэг юм бий болжээ.
Эхэндээ хөгжүүлэлтийн баг, засвар үйлчилгээний баг тусдаа байдаг байв. Хоорондоо бараг хамааралгүй ажилладаг байсан байна. Яваандаа ачаалал, өөрчлөгдөх давтамж нэмэгдэн, бизнесийн нөхцөл хурдан өөрчлөгдөх болсоноос хөгжүүлэлт дуусангуут хугацаа алдалгүй хэрэглэгчийн гар дээр хүргэх, хөгжүүлэлт болон засвар үйлчилгээний баг харилцан уялдаатай ажиллах шаардлага бий болж, зардал хэмнэх, үр дүнтэй ажиллахын тулд тусдаа баг биш нэг баг болон ажиллах шаардлага буй болов. Тест ч гэсэн хөгжүүлэлтийн багийн ажлын салшгүй нэг хэсэг болов. Урд нь тест, хөгжүүлэлтийн баг тусдаа байх нь нийтлэг үзэгдэл байлаа. Ингэж DevOps гэдэг үг бий болжээ.
Цаг үетэйгээ зохицохгүй хуучинсаг арга 90-ээд оныг хүртэл амь бөхтэй оршин байв. Ерээд оны дунд үеэс хэсэг бүлэг хүмүүс урьд хожид үзэгдээгүй этгээд гаж аргаар DevOps-г хийх болов. Pair Programming, Standup Meeting, Automated Test, Test (Behavior) Driven Development, Continuous Integration, Continuous Delivery, Minimum Viable Program гэдэг сонсож дасаагүй үг дуулдах болжээ.
Хэн хамгийн хямд зардлаар, хамгийн богино хугацаанд, чанартай бүтээгдэхүүн нийлүүлэх вэ гэдэг өрсөлдөөн өрнөж, янз бүрийн оролдлого туршилтын үр дүнд шинэ онол, үзэл баримтлалууд бий болов. Unified process, Enterprise Unified Process, Agile Unified Process, Iterative development, Adaptive development гэх мэт нэр томъёо сонсогдох боллоо. Энэ дотроос Scrum, Extreme Programming, Lean, Kanban-г дурдахгүй өнгөрч болохгүй.
Scrum: Менежерүүдээс эхтэй, давталттай хөгжүүлэлтийн арга. Аливаа шийдвэрийг менежерүүд гаргадаг учраас энэ арга хамгийн их түгжээ. Ойлгомжтой хэр нь хэрэгжүүлэхэд амаргүй гэлцдэг.
Extreme Programming (XP): Хөгжүүлэгчдийн олон жилийн туршлага, ноу хау шингэсэн аргачлал. Нэвтрүүлэхэд хялбар, шинжлэх ухаанч, тестийг эрчимтэй хийдэг арга. Эрсдлийг эрт илрүүлэх, хамгийн чухал зүйлээс эхэлж хөгжүүлэлтийг хийх, шинэ хувилбарыг хэрэглэгчийн гар дээр түргэн хүргэх, богино хугацаанд чанартай бүтээгдэхүүн нийлүүлэхийн тулд шаардлагагүй илүү процесыг хасч, хөгжүүлэлтийн ажлын хамгийн чухал хэсэг болох програмчлах, тестлэх ажиллагааг оновчтой, үр дүнтэй болгоход түлхүү анхаарна. Хөгжүүлэлт тестээр эхлээд тестээр дуусна (TDD – automated test, CI/CD).
Lean Development: XP, Scrum-н давуу талуудыг Lean practice-аар баяжуулсан Toyota компанийн JIT production-с санаа авч, програм хангамж хөгжүүлэлтийн онцлогт тохируулан хувиргасан дэвшилтэт арга. Гол санаа: Үр ашиггүй, үнэ цэнгүй бүхнийг олж илрүүлэн (value chain map) арилгах, бүтээмж, чанарыг зогсолтгүй сайжруулах, бүтээгдэхүүн хэрэглэгчийн гар дээр очих хугацааг богиносгох, суралцах чадварыг бодит туршлага, шинжлэх ухааны үндэстэйгээр ахиулахыг оролддог. Тодорхой бус зүйлд цаг зарцуулахгүй, тодорхой болтол хойш нь тавина. Тодорхой болох үед бэлэн байхын тулд асуудлыг шийдвэрлэх 2–3 хувилбарыг дэвшүүлж судлагаа өрнүүлдэг. Аливаа зүйлийг сайжруулах арга замыг ямагт эрэлхийлэх, суралцах чадварыг чухалчилдаг.
Kanban Development (Самбарын арга): Toyota Production System (JIT production, Lean Producition)-с үүсэлтэй юуг хэзээ ямар хэмжээгээр хийх вэ? гэдэг шийдвэрийг гаргах, хөгжүүлэлтийн явцыг маш энгийнээр бүгдэд ойлгомжтойгоор дүрслэн харуулах арга. Хийх ёстой, хийгдэж буй, дууссан ажлыг хэдийд ч шууд мэдэх боломжтой. Үүнийг самбар (whiteboard), наалт (sticker), зориулалтын програм ашиглаад амархан гүйцэтгэж болдог.
Одоо үед
Интернэт, ухаалаг утасны хэрэглээ ихэсч, нийгмийн сүлжээ бий болсоноор системийн ачаалал, урьд хожид үзэгдээгүй хэмжээгээр өсч, их хэмжээний мэдээлэл хуримтлагдав. Түүнийг хурдан, үр ашигтай боловсруулах, хэрэглэгчийн зан үйлийг тандан, түүнд тохирсон өөрчлөлтийг цаг алдалгүй хийх бодит шаардлага тулгарах боллоо. Урд нь релийзийг сар жилээр төлөвлөдөг байсан бол одоо долоо хоног, өдөр, бүр цагаар төлөвлөдөг, хийдэг болжээ. Үүнийг дагаад клауд, сервергүй (serverless) орчин, төвлөрсөн бус тархсан хэлбэр рүү зогсолтгүй шилжиж, operations гэдэг юмыг халах, зөвхөн хөгжүүлэлт, тестэнд анхаарлаа төвлөрүүлж ашиглалтын зардлыг бууруулахыг эрмэлзэх боллоо. DevOps-г хөнгөвчилсөн tool, system бий болж, серверийн хэвийн ажилллагааг AI ашиглан хянах, серверийн төлвийг DevOps-н багт шуурхай мэдээлэх chatbot хүртэл бий болов.
Ирээдүйд
Web 3.0-н эрин юу юугүй ирж, бүх зүйл тархсан хэлбэрт шилжиж, мэдээллийн нууцлалыг хангах зорилгоор блокчэинийг түлхүү ашиглах болно. Жинхэнээсээ сервергүй програм олноороо бий болно.
Хэрэгцээ шаардлага, хөгжүүлэгч багийн баримтлах бодлогоос хамаараад нэг хэсэг нь ops-г өөрсдөө хийхийг эрмэлзнэ. Гэхдээ илүү бүрэн автоматжуулсан, хүний оролцоо бага, хиймэл оюуныг түлхүү ашигласан байх болно. ChatOps, VoiceOps түлхүү бий болно. Серверийн ачаалал нэмэгдэх, ямар нэгэн асуудал үүсэхээс өмнө урьдчилан таамаглах чадвартай болно.
