សួស្តី ហាប! ខ្ញុំសូមបង្ហាញជូនអ្នកនូវការបកប្រែអត្ថបទ "ប្រភពដើមនៃ DevOps: តើមានឈ្មោះអ្វី?" ដោយ Steve Mezak ។

អាស្រ័យលើទស្សនៈរបស់អ្នក DevOps នឹងប្រារព្ធខួបលើកទីប្រាំបួន ឬដប់ឆ្នាំនេះ។ ក្នុងឆ្នាំ 2016 របាយការណ៍របស់ RightScales 'State of the Cloud បានកត់សម្គាល់ថា 70 ភាគរយនៃ SMBs កំពុងទទួលយកការអនុវត្ត DevOps ។ រាល់សូចនាករដែលបង្កើតបានពិន្ទុនេះបានកើនឡើងតាំងពីពេលនោះមក។ នៅពេលដែល DevOps រៀបចំខ្លួនដើម្បីឈានចូលទសវត្សរ៍ទីពីរ វាជាការប្រសើរណាស់ក្នុងការដើរចុះតាមច្រកផ្លូវ ហើយត្រឡប់ទៅប្រភពដើមនៃ DevOps ហើយសូម្បីតែប្រភពដើមនៃឈ្មោះខ្លួនឯង។

មុនឆ្នាំ 2007: ខ្សែសង្វាក់ដ៏ល្អឥតខ្ចោះនៃព្រឹត្តិការណ៍

មុនឆ្នាំ 2007 កាលៈទេសៈជាបន្តបន្ទាប់បានផ្តល់កំណើតដល់អ្វីដែលត្រូវបានគេស្គាល់ថាជា DevOps សព្វថ្ងៃនេះ។

គ្មានខ្លាញ់ បានបង្ហាញខ្លួនរួចហើយថាជាការអនុវត្តល្អបំផុត។ ត្រូវបានគេស្គាល់ផងដែរថាជា ប្រព័ន្ធផលិតកម្មតូយ៉ូតា, Lean Manufacturing ខិតខំបង្កើនប្រសិទ្ធភាពដំណើរការនៅជាន់ផលិត។ (ដោយវិធីនេះ ការគ្រប់គ្រងរបស់តូយ៉ូតាត្រូវបានបំផុសគំនិតដំបូងដោយវិធីសាស្ត្រខ្សែដំឡើងដើមដែលណែនាំដោយក្រុមហ៊ុនហ្វដម៉ូទ័រ)។ ការកែលម្អជាបន្តបន្ទាប់ គឺជា Mantra សម្រាប់ការផលិតគ្មានខ្លាញ់។ នៅក្នុងការអនុវត្ត ផ្លូវខាងក្រោមត្រូវបានវាយតម្លៃឥតឈប់ឈរ៖

រក្សាកម្រិតសារពើភ័ណ្ឌនៃវត្ថុធាតុដើម និងផលិតផលសម្រេចឱ្យបានអប្បបរមា. ការផលិតគ្មានខ្លាញ់មានន័យថាជាចំនួនអប្បបរមានៃសារពើភ័ណ្ឌនៃវត្ថុធាតុដើមសម្រាប់ផលិតទំនិញ និងចំនួនអប្បបរមានៃផលិតផលសម្រេចដែលរង់ចាំការបញ្ជាទិញ ឬដឹកជញ្ជូន។
កាត់បន្ថយជួរនៃការបញ្ជាទិញ. តាមឧត្ដមគតិ ការបញ្ជាទិញដែលបានទទួលភ្លាមៗផ្លាស់ទីទៅស្ថានភាពដែលបានបញ្ចប់។ រង្វាស់សំខាន់សម្រាប់ការផលិតគ្មានខ្លាញ់នឹងតែងតែជាពេលវេលាចាប់ពីការទទួលការបញ្ជាទិញរហូតដល់ការដឹកជញ្ជូន។
ប្រសិទ្ធភាពអតិបរមានៃដំណើរការផលិត. ដំណើរការវិស្វកម្មឡើងវិញ និងស្វ័យប្រវត្តិកម្មដែលប្រសើរឡើងកំពុងរួមបញ្ចូលគ្នាដើម្បីផលិតទំនិញឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន។ គ្រប់ផ្នែកនៃផលិតកម្មនៅតាមផ្លូវ (ការកាត់ ការផ្សារ ការផ្គុំ ការធ្វើតេស្ត។ល។) ត្រូវបានវាយតម្លៃថាគ្មានប្រសិទ្ធភាព។

នៅក្នុងពិភពព័ត៌មានវិទ្យា វិធីសាស្រ្តបែបប្រពៃណីនៃគំរូទឹកជ្រោះនៃការអភិវឌ្ឍន៍កម្មវិធីបានផ្ដល់មធ្យោបាយដល់វិធីសាស្រ្តដដែលៗដែលមានល្បឿនលឿនដូចជា រហ័សរហួន. ល្បឿនគឺជាការប្រមូលផ្ដុំគ្នាដែលមានគុណភាព ទោះបីពេលខ្លះគុណភាពបានរងទុក្ខក្នុងការស្វែងរកការអភិវឌ្ឍន៍ និងការដាក់ពង្រាយយ៉ាងឆាប់រហ័ស។ នៅក្នុងវិធីដូចគ្នានេះ cloud computing ជាពិសេស ហេដ្ឋារចនាសម្ព័ន្ធជាសេវាកម្ម (IaaS) និង វេទិកាជាសេវា (PaaS) បានបង្ហាញឱ្យឃើញខ្លួនឯងថាជាដំណោះស្រាយចាស់ទុំក្នុងដំណើរការ IT និងហេដ្ឋារចនាសម្ព័ន្ធ។

ជាចុងក្រោយ ថ្មីៗនេះ ប្រអប់ឧបករណ៍បានចាប់ផ្តើមលេចឡើងសម្រាប់ សមាហរណកម្មបន្ត (CI) ។ គំនិតនៃឧបករណ៍ CI ត្រូវបានកើត និងបង្ហាញដោយ Gradi Booch ត្រឡប់មកវិញក្នុងឆ្នាំ 1991 នៅក្នុងវិធី Booch របស់គាត់។

២០០៧-២០០៨៖ បែលហ្សិកខកចិត្ត

លោក Patrick Debois ដែលជាអ្នកប្រឹក្សាយោបល់ អ្នកគ្រប់គ្រងគម្រោង និងជាអ្នកអនុវត្ត Agile ជនជាតិបែលហ្ស៊ិក បានទទួលយកការងារមួយពីក្រសួងរដ្ឋាភិបាលបែលហ្ស៊ិក ដើម្បីជួយសម្រួលដល់ការធ្វើចំណាកស្រុកមជ្ឈមណ្ឌលទិន្នន័យ។ ជាពិសេស លោកទទួលខុសត្រូវចំពោះការធ្វើតេស្តវិញ្ញាបនបត្រ និងការធ្វើតេស្តត្រៀមខ្លួន។ ភារកិច្ចរបស់លោកតម្រូវឱ្យលោកសម្របសម្រួលសកម្មភាព និងកសាងទំនាក់ទំនងរវាងក្រុមអភិវឌ្ឍន៍កម្មវិធី និងក្រុមប្រតិបត្តិការ។ ម៉ាស៊ីនបម្រើមូលដ្ឋានទិន្នន័យ និងបណ្តាញ។ ការខកចិត្តរបស់គាត់ចំពោះកង្វះភាពស្អិតរមួត និងជញ្ជាំងដែលបំបែកវិធីសាស្រ្តអភិវឌ្ឍន៍ និងប្រតិបត្តិការបានជំរុញឱ្យគាត់មិនពេញចិត្ត។ បំណងប្រាថ្នារបស់លោក Desbois សម្រាប់ការកែលម្អមិនយូរប៉ុន្មានបាននាំគាត់ទៅរកសកម្មភាព។
នៅឯសន្និសីទ Agile ឆ្នាំ 2008 នៅទីក្រុង Toronto លោក Andrew Schaefer បានស្នើឱ្យមានការសម្របសម្រួលកិច្ចប្រជុំក្រៅផ្លូវការដែលបានរៀបចំជាពិសេសដើម្បីពិភាក្សាអំពីប្រធានបទ "ហេដ្ឋារចនាសម្ព័ន្ធរហ័សរហួន"ហើយមានតែមនុស្សម្នាក់ប៉ុណ្ណោះដែលមកពិភាក្សាលើប្រធានបទ៖ លោក Patrick DeBois ។ ការពិភាក្សា និងការផ្លាស់ប្តូរគំនិតរបស់ពួកគេបានជំរុញគំនិតនៃការគ្រប់គ្រងប្រព័ន្ធ Agile ។ នៅឆ្នាំដដែលនោះ DeBois និង Schaefer បានបង្កើតក្រុមអ្នកគ្រប់គ្រងប្រព័ន្ធ Agile ដែលទទួលបានជោគជ័យកម្រិតមធ្យមនៅ Google ។

ឆ្នាំ ២០០៩៖ ករណីនៃកិច្ចសហប្រតិបត្តិការរវាង Dev និង Ops

នៅក្នុងសន្និសិទ O'Reilly Velocity បុគ្គលិក Flickr ពីរនាក់ដែលជាអនុប្រធានជាន់ខ្ពស់នៃប្រតិបត្តិការបច្ចេកទេស John Allspaw និង CTO Paul Hammond បានធ្វើបទបង្ហាញដ៏ល្បីល្បាញឥឡូវនេះ។ "ការដាក់ពង្រាយចំនួន 10 ក្នុងមួយថ្ងៃ៖ កិច្ចសហការ Dev និង Ops នៅ Flickr".

បទបង្ហាញគឺជារឿងល្ខោន ដោយ Allspaw និង Hammond បង្ហាញឡើងវិញនូវអន្តរកម្មដ៏ស្មុគស្មាញរវាងអ្នកតំណាងផ្នែកអភិវឌ្ឍន៍ និងផ្នែកប្រតិបត្តិការ ក្នុងអំឡុងពេលដំណើរការដាក់ឱ្យប្រើប្រាស់កម្មវិធី ដោយបញ្ចប់ដោយការចង្អុលម្រាមដៃ និងការរិះគន់តាមបន្ទាត់នៃ "វាមិនមែនជាកូដរបស់ខ្ញុំ វាជាកុំព្យូទ័ររបស់អ្នកទាំងអស់!" ការធ្វើបទបង្ហាញរបស់ពួកគេបានបញ្ជាក់ថា ជម្រើសដ៏សមហេតុផលតែមួយគត់គឺសម្រាប់ការអភិវឌ្ឍន៍កម្មវិធី និងសកម្មភាពដាក់ពង្រាយឱ្យមានភាពរលូន តម្លាភាព និងរួមបញ្ចូលគ្នាយ៉ាងពេញលេញ។ យូរ ៗ ទៅបទបង្ហាញនេះបានក្លាយជារឿងព្រេងនិទានហើយឥឡូវនេះត្រូវបានគេមើលឃើញជាប្រវត្តិសាស្ត្រថាជាព្រឹត្តិការណ៍ដ៏សំខាន់មួយនៅពេលដែលឧស្សាហកម្ម IT បានចាប់ផ្តើមអំពាវនាវរកវិធីសាស្រ្តដែលគេស្គាល់ថាជា DevOps ។

ឆ្នាំ 2010: DevOps នៅសហរដ្ឋអាមេរិក

ជាមួយនឹងការកើនឡើងជាបន្តបន្ទាប់ សន្និសិទ DevOpsDays ត្រូវបានធ្វើឡើងជាលើកដំបូងនៅសហរដ្ឋអាមេរិកនៅ Mountain View រដ្ឋកាលីហ្វ័រញ៉ា ភ្លាមៗបន្ទាប់ពីសន្និសីទ Velocity ប្រចាំឆ្នាំ។ ឆ្ពោះទៅមុខយ៉ាងលឿនដល់ឆ្នាំ 2018 ហើយមានសន្និសីទ DevOpsDays ច្រើនជាង 30 ដែលបានគ្រោងទុក រួមទាំងរាប់សិបនៅក្នុងសហរដ្ឋអាមេរិក។

ឆ្នាំ 2013: គម្រោង "Phoenix"

សម្រាប់ពួកយើងជាច្រើន ពេលវេលាដ៏គួរឱ្យកត់សម្គាល់មួយទៀតនៅក្នុងប្រវត្តិសាស្រ្តរបស់ DevOps គឺការបោះពុម្ពសៀវភៅ "The Phoenix Project" ដោយ Gene Kim, Kevin Behr និង George Safford ។ ប្រលោមលោកនេះប្រាប់ពីរឿងរ៉ាវរបស់អ្នកគ្រប់គ្រងផ្នែកព័ត៌មានវិទ្យាម្នាក់ដែលរកឃើញថាខ្លួនគាត់ស្ថិតក្នុងស្ថានភាពអស់សង្ឃឹម៖ គាត់ត្រូវបានប្រគល់ភារកិច្ចឱ្យជួយសង្គ្រោះគម្រោងពាណិជ្ជកម្មអេឡិចត្រូនិកដ៏សំខាន់មួយដែលបានដំណើរការខុស។ អ្នកណែនាំអាថ៌កំបាំងរបស់អ្នកគ្រប់គ្រង - សមាជិកនៃក្រុមប្រឹក្សាភិបាលដែលមានចំណង់ចំណូលចិត្តចំពោះវិធីសាស្រ្តផលិតកម្មគ្មានខ្លាញ់ - ណែនាំវិធីថ្មីដល់តួអង្គសំខាន់ក្នុងការគិតអំពី IT និងការអភិវឌ្ឍន៍កម្មវិធី ដោយរំពឹងពីគំនិតរបស់ DevOps ។ ដោយវិធីនេះ "គម្រោង Phoenix" បានបំផុសគំនិតយើងឱ្យសរសេរសៀវភៅ "Outsource or other...

DevOps សម្រាប់អនាគត

វាមានតម្លៃពិពណ៌នា DevOps ជាដំណើរមួយ ឬប្រហែលជាសេចក្តីប្រាថ្នា ជាជាងគោលដៅចុងក្រោយ។ DevOps ដូចជាការផលិតគ្មានខ្លាញ់ ខិតខំធ្វើឱ្យប្រសើរឡើងជាបន្តបន្ទាប់ បង្កើនផលិតភាព និងប្រសិទ្ធភាព និងសូម្បីតែការដាក់ឱ្យប្រើប្រាស់ជាបន្តបន្ទាប់។ ឧបករណ៍ស្វ័យប្រវត្តិដើម្បីគាំទ្រ DevOps បន្តវិវត្ត។

ជាច្រើនត្រូវបានសម្រេចចាប់តាំងពីការចាប់ផ្តើមនៃ DevOps ក្នុងទសវត្សរ៍ចុងក្រោយនេះ ហើយយើងរំពឹងថានឹងឃើញកាន់តែច្រើននៅក្នុងឆ្នាំ 2018 និងលើសពីនេះ។

ប្រភព: www.habr.com