តើវាពិបាកក្នុងការចាប់យកចំណុចសំខាន់នៅពេលនិយាយអំពី DevOps មែនទេ? យើងបានប្រមូលសម្រាប់អ្នកនូវភាពស្រដៀងគ្នាដ៏រស់រវើក រូបមន្តដ៏ទាក់ទាញ និងដំបូន្មានពីអ្នកជំនាញ ដែលនឹងជួយសូម្បីតែអ្នកមិនមែនជាអ្នកឯកទេសឈានដល់ចំណុចនោះ។ នៅចុងបញ្ចប់ ប្រាក់រង្វាន់គឺ DevOps ផ្ទាល់ខ្លួនរបស់បុគ្គលិក Red Hat។
ពាក្យ DevOps មានដើមកំណើតកាលពី 10 ឆ្នាំមុន ហើយបានចេញពី hashtag Twitter ទៅជាចលនាវប្បធម៌ដ៏មានឥទ្ធិពលនៅក្នុងពិភពព័ត៌មានវិទ្យា ដែលជាទស្សនវិជ្ជាពិតដែលលើកទឹកចិត្តអ្នកអភិវឌ្ឍន៍ឱ្យធ្វើអ្វីៗបានលឿនជាងមុន ពិសោធន៍ និងធ្វើម្តងទៀតទៅមុខ។ DevOps បានក្លាយជាការភ្ជាប់គ្នាយ៉ាងអធិកអធមជាមួយនឹងគំនិតនៃការផ្លាស់ប្តូរឌីជីថល។ ប៉ុន្តែដូចដែលកើតឡើងជាញឹកញាប់ជាមួយវាក្យស័ព្ទ IT ក្នុងរយៈពេលដប់ឆ្នាំកន្លងមកនេះ DevOps បានទទួលនិយមន័យ ការបកស្រាយ និងការយល់ខុសជាច្រើនអំពីខ្លួនវា។
ដូច្នេះហើយ ជាញឹកញាប់អ្នកអាចឮសំណួរអំពី DevOps ដូចជា តើវាដូចគ្នាទៅនឹង agile ដែរឬទេ? ឬនេះជាវិធីសាស្រ្តពិសេស? ឬវាគ្រាន់តែជាសទិសន័យផ្សេងទៀតសម្រាប់ពាក្យថា «សហការ»?
DevOps រួមបញ្ចូលនូវគំនិតផ្សេងៗគ្នាជាច្រើន (ការចែកចាយបន្ត ការរួមបញ្ចូលជាបន្តបន្ទាប់ ស្វ័យប្រវត្តិកម្ម។ ទោះជាយ៉ាងណាក៏ដោយ ជំនាញនេះមានប្រយោជន៍ខ្លាំងណាស់ មិនថាអ្នកកំពុងព្យាយាមបញ្ចេញគំនិតរបស់អ្នកទៅកាន់ថ្នាក់លើរបស់អ្នក ឬគ្រាន់តែប្រាប់នរណាម្នាក់ពីគ្រួសារ ឬមិត្តភក្តិរបស់អ្នកអំពីការងាររបស់អ្នក។ ដូច្នេះហើយ ចូរយើងទុកចោលនូវចំណុចសំខាន់ៗនៃពាក្យ DevOps សម្រាប់ពេលនេះ ហើយផ្តោតលើរូបភាពធំ។
តើអ្វីទៅជា DevOps: 6 និយមន័យ និងអាណាឡូក
យើងបានស្នើឱ្យអ្នកជំនាញពន្យល់ពីខ្លឹមសារនៃ DevOps ឱ្យបានសាមញ្ញ និងខ្លីតាមដែលអាចធ្វើបាន ដើម្បីឱ្យតម្លៃរបស់វាច្បាស់លាស់សម្រាប់អ្នកអានជាមួយនឹងកម្រិតនៃចំណេះដឹងបច្ចេកទេសណាមួយ។ ដោយផ្អែកលើលទ្ធផលនៃការសន្ទនាទាំងនេះ យើងបានជ្រើសរើសភាពស្រដៀងគ្នា និងទម្រង់ដ៏ទាក់ទាញបំផុត ដែលនឹងជួយអ្នកបង្កើតរឿងរបស់អ្នកអំពី DevOps ។
1. DevOps គឺជាចលនាវប្បធម៌
"DevOps គឺជាចលនាវប្បធម៌ដែលភាគីទាំងពីរ (អ្នកបង្កើតកម្មវិធី និងអ្នកឯកទេសផ្នែកប្រតិបត្តិការប្រព័ន្ធ IT) ទទួលស្គាល់ថាកម្មវិធីមិននាំមកនូវអត្ថប្រយោជន៍ពិតប្រាកដរហូតដល់នរណាម្នាក់ចាប់ផ្តើមប្រើវា៖ អតិថិជន អតិថិជន បុគ្គលិក មិនមែនជាចំណុចនោះទេ" Eveline Oehrlich បាននិយាយថា ការស្រាវជ្រាវជាន់ខ្ពស់ អ្នកវិភាគនៅវិទ្យាស្ថាន DevOps ។ "ដូច្នេះ ភាគីទាំងពីររួមគ្នាធានាឱ្យបាននូវការផ្តល់កម្មវិធីដែលមានគុណភាពខ្ពស់ និងឆាប់រហ័ស។"
2. DevOps គឺនិយាយអំពីការផ្តល់សិទ្ធិអំណាចដល់អ្នកអភិវឌ្ឍន៍។
"DevOps ផ្តល់សិទ្ធិអំណាចដល់អ្នកអភិវឌ្ឍន៍ដើម្បីធ្វើជាម្ចាស់កម្មវិធី ដំណើរការពួកវា និងគ្រប់គ្រងការចែកចាយពីដើមដល់ចប់។"
លោក Jai Schniepp នាយកនៃវេទិកា DevOps នៅក្រុមហ៊ុនធានារ៉ាប់រង Liberty Mutual មានប្រសាសន៍ថា "ជាធម្មតា DevOps ត្រូវបាននិយាយអំពីជាមធ្យោបាយមួយដើម្បីបង្កើនល្បឿននៃការបញ្ជូនកម្មវិធីទៅផលិតកម្មដោយការកសាង និងអនុវត្តដំណើរការដោយស្វ័យប្រវត្តិ" ។ «ប៉ុន្តែសម្រាប់ខ្ញុំ វាជារឿងសំខាន់ជាងនេះ»។ DevOps ផ្តល់អំណាចដល់អ្នកអភិវឌ្ឍន៍ដើម្បីធ្វើជាម្ចាស់កម្មវិធី ឬផ្នែកជាក់លាក់នៃកម្មវិធី ដំណើរការពួកវា និងគ្រប់គ្រងការចែកចាយរបស់ពួកគេពីដើមដល់ចប់។ DevOps លុបបំបាត់ការភាន់ច្រលំទំនួលខុសត្រូវ និងណែនាំអ្នកគ្រប់គ្នាដែលពាក់ព័ន្ធក្នុងការបង្កើតហេដ្ឋារចនាសម្ព័ន្ធដែលជំរុញដោយអ្នកអភិវឌ្ឍន៍ដោយស្វ័យប្រវត្តិ។
3. DevOps និយាយអំពីកិច្ចសហការក្នុងការបង្កើត និងចែកចាយកម្មវិធី។
លោក Gur Staf ប្រធាន និងជាប្រធានផ្នែកស្វ័យប្រវត្តិកម្មអាជីវកម្មឌីជីថលនៅ BMC មានប្រសាសន៍ថា "និយាយឱ្យសាមញ្ញ DevOps គឺជាវិធីសាស្រ្តមួយក្នុងការផលិត និងចែកចាយកម្មវិធីដែលមនុស្សគ្រប់គ្នាធ្វើការជាមួយគ្នា" ។
4. DevOps គឺជាបំពង់មួយ។
"ការផ្គុំឧបករណ៍បញ្ជូនគឺអាចធ្វើទៅបានលុះត្រាតែគ្រប់ផ្នែកទាំងអស់ត្រូវគ្នា"។
បុគ្គលិក Gur បន្តថា៖ "ខ្ញុំនឹងប្រៀបធៀប DevOps ទៅនឹងបន្ទាត់ដំឡើងរថយន្ត" ។ - គំនិតគឺត្រូវរចនា និងបង្កើតផ្នែកទាំងអស់ជាមុន ដូច្នេះពួកវាអាចផ្គុំឡើងបានដោយមិនចាំបាច់មានការកែតម្រូវបុគ្គល។ ការផ្គុំឧបករណ៍បញ្ជូនគឺអាចធ្វើទៅបានលុះត្រាតែគ្រប់ផ្នែកទាំងអស់សមជាមួយគ្នា។ អ្នកដែលរចនា និងបង្កើតម៉ាស៊ីនត្រូវពិចារណាពីរបៀបដំឡើងវាទៅនឹងតួ ឬស៊ុម។ អ្នកដែលធ្វើហ្រ្វាំងត្រូវគិតពីកង់ជាដើម។ ដូចគ្នានេះដែរគួរតែជាការពិតជាមួយកម្មវិធី។
អ្នកអភិវឌ្ឍន៍ដែលបង្កើតតក្កវិជ្ជាអាជីវកម្ម ឬចំណុចប្រទាក់អ្នកប្រើត្រូវតែគិតអំពីមូលដ្ឋានទិន្នន័យដែលរក្សាទុកព័ត៌មានអតិថិជន វិធានការសុវត្ថិភាពដើម្បីការពារទិន្នន័យអ្នកប្រើប្រាស់ និងរបៀបដែលអ្វីៗទាំងអស់នេះនឹងដំណើរការនៅពេលដែលសេវាកម្មចាប់ផ្តើមបម្រើដល់អ្នកប្រើប្រាស់ដ៏ធំ ប្រហែលជាសូម្បីតែទស្សនិកជនអ្នកប្រើប្រាស់រាប់លានដុល្លារ។ "
“ការឱ្យមនុស្សសហការគ្នា និងគិតអំពីផ្នែកនៃការងារដែលអ្នកដទៃកំពុងធ្វើ ជាជាងផ្តោតតែលើកិច្ចការផ្ទាល់ខ្លួន គឺជាឧបសគ្គដ៏ធំបំផុតក្នុងការយកឈ្នះ។ ប្រសិនបើអ្នកអាចធ្វើវាបាន អ្នកមានឱកាសដ៏ល្អនៃការផ្លាស់ប្តូរឌីជីថល” បុគ្គលិក Gur បន្ថែម។
5. DevOps គឺជាការរួមបញ្ចូលគ្នាដ៏ត្រឹមត្រូវនៃមនុស្ស ដំណើរការ និងស្វ័យប្រវត្តិកម្ម
Jayne Groll នាយកប្រតិបត្តិនៃវិទ្យាស្ថាន DevOps បានផ្តល់ភាពស្រដៀងគ្នាដ៏អស្ចារ្យមួយដើម្បីពន្យល់ DevOps ។ នៅក្នុងពាក្យរបស់នាង "DevOps គឺដូចជារូបមន្តមួយដែលមានបីប្រភេទសំខាន់ៗនៃគ្រឿងផ្សំ: មនុស្ស ដំណើរការ និងស្វ័យប្រវត្តិកម្ម។ សារធាតុផ្សំទាំងនេះភាគច្រើនអាចត្រូវបានគេយកមកពីតំបន់ និងប្រភពផ្សេងទៀត៖ Lean, Agile, SRE, CI/CD, ITIL, ភាពជាអ្នកដឹកនាំ, វប្បធម៌, ឧបករណ៍។ អាថ៌កំបាំងចំពោះ DevOps ដូចជារូបមន្តដ៏ល្អណាមួយគឺរបៀបដើម្បីទទួលបានសមាមាត្រត្រឹមត្រូវ និងលាយគ្រឿងផ្សំទាំងនេះដើម្បីបង្កើនល្បឿន និងប្រសិទ្ធភាពនៃការបង្កើត និងបញ្ចេញកម្មវិធី។
6. DevOps គឺជាពេលដែលអ្នកសរសេរកម្មវិធីធ្វើការដូចជាក្រុម Formula 1
“ការប្រណាំងមិនត្រូវបានគ្រោងទុកពីដើមដល់ចប់ទេ ប៉ុន្តែផ្ទុយទៅវិញ ពីចប់ដល់ចាប់ផ្តើម”។
Chris Short អ្នកគ្រប់គ្រងជាន់ខ្ពស់ផ្នែកទីផ្សារវេទិកាលើពពកនៅ Red Hat និងអ្នកបោះពុម្ពផ្សាយព្រឹត្តិបត្រ DevOps'ish មានប្រសាសន៍ថា "នៅពេលខ្ញុំនិយាយអំពីអ្វីដែលត្រូវរំពឹងពីគំនិតផ្តួចផ្តើម DevOps ខ្ញុំគិតថាក្រុមប្រណាំង NASCAR ឬ Formula 1 ជាឧទាហរណ៍" ។ - អ្នកដឹកនាំក្រុមបែបនេះមានគោលដៅមួយ៖ ដើម្បីយកកន្លែងខ្ពស់បំផុតនៅចុងបញ្ចប់នៃការប្រណាំង ដោយគិតគូរពីធនធានដែលមានសម្រាប់ក្រុម និងបញ្ហាប្រឈមដែលកើតឡើង។ ក្នុងករណីនេះ ការប្រណាំងត្រូវបានគ្រោងទុកមិនមែនពីដើមដល់ចប់ទេ ប៉ុន្តែផ្ទុយទៅវិញ ពីចប់ដល់ចាប់ផ្តើម។ ទីមួយ គោលដៅដែលមានមហិច្ឆតាត្រូវបានកំណត់ ហើយបន្ទាប់មកវិធីដើម្បីសម្រេចបានវាត្រូវបានកំណត់។ បន្ទាប់មក ពួកគេត្រូវបានបំបែកជាកិច្ចការរង ហើយផ្ទេរទៅសមាជិកក្រុម»។
“ក្រុមចំណាយពេលពេញមួយសប្តាហ៍មុនពេលការប្រណាំងដើម្បីបញ្ចប់ទីលាន។ គាត់ហ្វឹកហាត់កម្លាំង និង cardio ដើម្បីរក្សារាងសម្រាប់ថ្ងៃប្រណាំងដ៏ស្វិតស្វាញ។ ការអនុវត្តការងាររួមគ្នាដើម្បីដោះស្រាយបញ្ហាដែលអាចកើតឡើងក្នុងអំឡុងពេលប្រណាំង។ ដូចគ្នានេះដែរ ក្រុមអភិវឌ្ឍន៍គួរតែបណ្តុះបណ្តាលជំនាញនៃការចេញផ្សាយកំណែថ្មីឱ្យបានញឹកញាប់។ ប្រសិនបើអ្នកមានជំនាញបែបនេះ និងប្រព័ន្ធសុវត្ថិភាពដែលដំណើរការបានល្អ ការចាប់ផ្តើមនៃកំណែថ្មីទៅក្នុងផលិតកម្មក៏កើតឡើងញឹកញាប់ជាងមុនផងដែរ។ នៅក្នុងទស្សនៈពិភពលោកនេះ ល្បឿនកើនឡើងមានន័យថាសុវត្ថិភាពកើនឡើង” Short និយាយ។
Short បន្ថែមថា "វាមិនមែននិយាយអំពីការធ្វើ 'រឿងត្រឹមត្រូវ' ទេ វានិយាយអំពីការលុបបំបាត់អ្វីៗជាច្រើនតាមដែលអាចធ្វើទៅបាន ដែលឈរក្នុងផ្លូវនៃលទ្ធផលដែលចង់បាន។ សហការ និងសម្របខ្លួនដោយផ្អែកលើមតិកែលម្អដែលអ្នកទទួលបានក្នុងពេលជាក់ស្តែង។ ត្រៀមខ្លួនសម្រាប់ភាពមិនប្រក្រតី និងធ្វើការដើម្បីកែលម្អគុណភាព ដើម្បីកាត់បន្ថយផលប៉ះពាល់របស់វាទៅលើវឌ្ឍនភាពឆ្ពោះទៅរកគោលដៅរបស់អ្នក។ នេះគឺជាអ្វីដែលកំពុងរង់ចាំយើងនៅក្នុងពិភព DevOps ។
របៀបធ្វើមាត្រដ្ឋាន DevOps: គន្លឹះ 10 ពីអ្នកជំនាញ
វាគ្រាន់តែថា DevOps និង DevOps ដ៏ធំគឺជារឿងខុសគ្នាទាំងស្រុង។ យើងនឹងប្រាប់អ្នកពីរបៀបដើម្បីជំនះឧបសគ្គនៅតាមផ្លូវពីទីមួយទៅទីពីរ។
សម្រាប់ស្ថាប័នជាច្រើន ការធ្វើដំណើរទៅកាន់ DevOps ចាប់ផ្តើមយ៉ាងងាយស្រួល និងរីករាយ។ ក្រុមតូចៗដែលមានចំណង់ចំណូលចិត្តត្រូវបានបង្កើតឡើង ដំណើរការចាស់ត្រូវបានជំនួសដោយក្រុមថ្មី ហើយភាពជោគជ័យដំបូងមិនយូរប៉ុន្មាននឹងមកដល់។
លោក Ben Grinnell នាយកគ្រប់គ្រង និងជាប្រធានផ្នែកឌីជីថលនៅក្រុមហ៊ុនប្រឹក្សា North Highland មានប្រសាសន៍ថា Alas នេះគ្រាន់តែជាការយល់ឃើញមិនពិត ដែលជាការបំភាន់នៃវឌ្ឍនភាព។ ការឈ្នះដំបូងពិតជាមានការលើកទឹកចិត្ត ប៉ុន្តែវាមិនអាចជួយសម្រេចបាននូវគោលដៅចុងក្រោយនៃការទទួលយក DevOps យ៉ាងទូលំទូលាយនៅទូទាំងស្ថាប័ននោះទេ។
វាងាយមើលឃើញថាលទ្ធផលគឺជាវប្បធម៌នៃការបែងចែករវាង "យើង" និង "ពួកគេ" ។
Ben Grinnell ពន្យល់ថា "ជាញឹកញាប់ អង្គការនានាចាប់ផ្តើមគម្រោងត្រួសត្រាយផ្លូវទាំងនេះ ដោយគិតថាពួកគេនឹងត្រួសត្រាយផ្លូវសម្រាប់ DevOps ដែលកំពុងពេញនិយម ដោយមិនគិតពីថាតើអ្នកផ្សេងទៀតនឹងអាច ឬមានឆន្ទៈក្នុងការដើរតាមផ្លូវនោះ" ។ - ក្រុមសម្រាប់អនុវត្តគម្រោងបែបនេះជាធម្មតាត្រូវបានជ្រើសរើសពី "Varangians" ដែលមានទំនុកចិត្តលើខ្លួនឯង ដែលបានធ្វើអ្វីមួយស្រដៀងគ្នារួចហើយនៅកន្លែងផ្សេងទៀត ប៉ុន្តែថ្មីសម្រាប់ស្ថាប័នរបស់អ្នក។ ទន្ទឹមនឹងនេះ ពួកគេត្រូវបានលើកទឹកចិត្តឱ្យបំបែក និងបំផ្លាញច្បាប់ដែលនៅជាប់នឹងអ្នកផ្សេង។ វាងាយមើលឃើញថាលទ្ធផលគឺជាវប្បធម៌នៃ "យើង" និង "ពួកគេ" ដែលរារាំងការផ្ទេរចំណេះដឹងនិងជំនាញ។
“ហើយបញ្ហាវប្បធម៌នេះគ្រាន់តែជាហេតុផលមួយដែល DevOps ពិបាកក្នុងការធ្វើមាត្រដ្ឋាន។ ក្រុម DevOps កំពុងប្រឈមមុខនឹងបញ្ហាប្រឈមផ្នែកបច្ចេកទេសកើនឡើង ដែលជាតួយ៉ាងនៃក្រុមហ៊ុនដំបូងគេផ្នែក IT ដែលរីកចម្រើនយ៉ាងឆាប់រហ័ស" លោក Steve Newman ស្ថាបនិក និងជាប្រធានក្រុមហ៊ុន Scalyr បាននិយាយ។
“នៅក្នុងពិភពសម័យទំនើប សេវាកម្មផ្លាស់ប្តូរភ្លាមៗនៅពេលដែលតម្រូវការកើតឡើង។ លោក Steve Newman បន្ថែមថា វាពិតជាល្អណាស់ក្នុងការអនុវត្ត និងអនុវត្តមុខងារថ្មីៗជាប្រចាំ ប៉ុន្តែការសម្របសម្រួលដំណើរការនេះ និងការលុបបំបាត់បញ្ហាដែលកើតឡើងគឺជាការឈឺក្បាលពិតប្រាកដ។ - នៅក្នុងអង្គការដែលរីកចម្រើនយ៉ាងឆាប់រហ័ស វិស្វករលើក្រុមឆ្លងមុខងារ តស៊ូដើម្បីរក្សាភាពមើលឃើញទៅជាការផ្លាស់ប្តូរ និងផលប៉ះពាល់កម្រិតភាពអាស្រ័យដែលវាបង្កើត។ ជាងនេះទៅទៀត វិស្វករមិនសប្បាយចិត្តនៅពេលដែលពួកគេបាត់បង់ឱកាសនេះ ហើយជាលទ្ធផល វាកាន់តែពិបាកសម្រាប់ពួកគេក្នុងការស្វែងយល់ពីខ្លឹមសារនៃបញ្ហាដែលកើតឡើង»។
តើធ្វើដូចម្តេចដើម្បីយកឈ្នះលើបញ្ហាប្រឈមទាំងនេះដែលបានពិពណ៌នាខាងលើ ហើយផ្លាស់ទីទៅការអនុម័តដ៏ធំនៃ DevOps នៅក្នុងអង្គការធំមួយ? អ្នកជំនាញជំរុញឱ្យមានការអត់ធ្មត់ បើទោះបីជាគោលដៅចុងក្រោយរបស់អ្នកគឺបង្កើនល្បឿនវដ្តនៃការអភិវឌ្ឍន៍កម្មវិធី និងដំណើរការអាជីវកម្មក៏ដោយ។
1. ចងចាំថាការផ្លាស់ប្តូរវប្បធម៌ត្រូវការពេលវេលា។
Jayne Groll នាយកប្រតិបត្តិវិទ្យាស្ថាន DevOps៖ “តាមគំនិតរបស់ខ្ញុំ ការពង្រីក DevOps គួរតែមានការបង្កើន និងម្តងហើយម្តងទៀត ដូចជាការអភិវឌ្ឍន៍ដ៏រហ័សរហួន (និងមានភាពស្មើគ្នាលើវប្បធម៌)។ Agile និង DevOps សង្កត់ធ្ងន់លើក្រុមតូចៗ។ ប៉ុន្តែនៅពេលដែលក្រុមទាំងនេះមានការកើនឡើងនៅក្នុងចំនួន និងការធ្វើសមាហរណកម្ម យើងបញ្ចប់ជាមួយនឹងមនុស្សកាន់តែច្រើនទទួលយកវិធីថ្មីនៃការងារ ហើយជាលទ្ធផលមានការផ្លាស់ប្តូរវប្បធម៌ដ៏ធំមួយ»។
2. ចំណាយពេលវេលាគ្រប់គ្រាន់ដើម្បីធ្វើផែនការ និងជ្រើសរើសវេទិកាមួយ។
Eran Kinsbruner អ្នកដឹកនាំផ្សាយដំណឹងល្អនៅ Perfecto៖ “សម្រាប់ការធ្វើមាត្រដ្ឋានទៅការងារ ក្រុម DevOps ត្រូវតែរៀនបញ្ចូលគ្នានូវដំណើរការប្រពៃណី ឧបករណ៍ និងជំនាញ ហើយបន្ទាប់មកបណ្តុះបន្តិចម្តងៗ និងធ្វើឱ្យមានស្ថេរភាពក្នុងដំណាក់កាលនីមួយៗនៃ DevOps ។ វាទាំងអស់ចាប់ផ្តើមជាមួយនឹងការធ្វើផែនការដោយប្រុងប្រយ័ត្ននៃរឿងរបស់អ្នកប្រើប្រាស់ និងតម្លៃស្ទ្រីម អមដោយការសរសេរកម្មវិធី និងការគ្រប់គ្រងកំណែដោយប្រើការអភិវឌ្ឍន៍ផ្អែកលើដើម ឬវិធីសាស្រ្តផ្សេងទៀតដែលស័ក្តិសមបំផុតសម្រាប់ការបំបែក និងបញ្ចូលកូដ។
“បន្ទាប់មកដល់ដំណាក់កាលធ្វើសមាហរណកម្ម និងការសាកល្បង ដែលវេទិកាដែលអាចធ្វើមាត្រដ្ឋានបានសម្រាប់ស្វ័យប្រវត្តិកម្មត្រូវបានទាមទាររួចហើយ។ នេះគឺជាកន្លែងដែលវាមានសារៈសំខាន់សម្រាប់ក្រុម DevOps ក្នុងការជ្រើសរើសវេទិកាត្រឹមត្រូវដែលសាកសមនឹងកម្រិតជំនាញរបស់ពួកគេ និងគោលដៅចុងក្រោយនៃគម្រោង។
ដំណាក់កាលបន្ទាប់គឺការដាក់ពង្រាយទៅផលិតកម្ម ហើយនេះគួរតែត្រូវបានស្វ័យប្រវត្តិយ៉ាងពេញលេញដោយប្រើឧបករណ៍ orchestration និងធុង។ វាមានសារៈសំខាន់ណាស់ក្នុងការមានបរិស្ថាននិម្មិតនៅគ្រប់ដំណាក់កាលនៃ DevOps (ម៉ាស៊ីនក្លែងធ្វើផលិតកម្ម បរិស្ថាន QA និងបរិយាកាសផលិតកម្មជាក់ស្តែង) ហើយតែងតែប្រើតែទិន្នន័យចុងក្រោយបំផុតសម្រាប់ការធ្វើតេស្តដើម្បីទទួលបានការសន្និដ្ឋានពាក់ព័ន្ធ។ ការវិភាគត្រូវតែឆ្លាតវៃ និងមានសមត្ថភាពដំណើរការទិន្នន័យធំ ជាមួយនឹងមតិកែលម្អរហ័ស និងអាចធ្វើសកម្មភាពបាន។"
3. យកកំហុសចេញពីការទទួលខុសត្រូវ។
Gordon Haff, RedHat Evangelist: “ការបង្កើតប្រព័ន្ធ និងបរិយាកាសដែលអនុញ្ញាត និងលើកទឹកចិត្តដល់ការពិសោធន៍ អនុញ្ញាតឱ្យមានអ្វីដែលគេស្គាល់ថាជាបរាជ័យជោគជ័យក្នុងការអភិវឌ្ឍន៍កម្មវិធីរហ័ស។ នេះមិនមែនមានន័យថា គ្មាននរណាទទួលខុសត្រូវចំពោះការបរាជ័យនោះទេ។ ជាការពិត ការកំណត់អត្តសញ្ញាណអ្នកណាជាអ្នកទទួលខុសត្រូវកាន់តែងាយស្រួលជាងមុន ដោយសារ "ការទទួលខុសត្រូវ" លែងមានន័យថា "បង្កគ្រោះថ្នាក់" ទៀតហើយ។ នោះគឺខ្លឹមសារនៃទំនួលខុសត្រូវផ្លាស់ប្តូរគុណភាព។ កត្តាទាំងបួនក្លាយជាកត្តាសំខាន់៖ វិសាលភាពនៃការរំខាន វិធីសាស្រ្ត ដំណើរការផលិត និងការលើកទឹកចិត្ត។ (អ្នកអាចអានបន្ថែមអំពីកត្តាទាំងនេះនៅក្នុងអត្ថបទរបស់ Gordon Huff “មេរៀន DevOps: ទិដ្ឋភាព 4 នៃការពិសោធន៍ដែលមានសុខភាពល្អ។”)
4. ជម្រះផ្លូវទៅមុខ
Ben Grinnell នាយកគ្រប់គ្រង និងជាប្រធានផ្នែកឌីជីថលនៅក្រុមហ៊ុនប្រឹក្សា North Highland៖ “ដើម្បីសម្រេចបាននូវមាត្រដ្ឋាន ខ្ញុំសូមណែនាំឱ្យចាប់ផ្តើមកម្មវិធី “ជម្រះផ្លូវ” រួមជាមួយនឹងគម្រោងត្រួសត្រាយផ្លូវ។ គោលដៅនៃកម្មវិធីនេះគឺដើម្បីសម្អាតសំរាមដែលអ្នកត្រួសត្រាយ DevOps ទុកចោល ដូចជាច្បាប់ហួសសម័យ និងអ្វីៗដូចនោះ ដើម្បីឱ្យផ្លូវឆ្ពោះទៅមុខនៅតែច្បាស់។
“ផ្តល់ឱ្យមនុស្សនូវការគាំទ្រពីអង្គការ និងសន្ទុះតាមរយៈការទំនាក់ទំនងដែលល្អលើសពីក្រុមត្រួសត្រាយ ដោយប្រារព្ធយ៉ាងទូលំទូលាយនូវភាពជោគជ័យនៃវិធីថ្មីនៃការងារ។ បង្វឹកមនុស្សដែលចូលរួមនៅក្នុងរលកបន្ទាប់នៃគម្រោង DevOps ហើយមានការភ័យខ្លាចចំពោះការប្រើប្រាស់ DevOps ជាលើកដំបូង។ ហើយត្រូវចាំថាមនុស្សទាំងនេះខុសពីអ្នកត្រួសត្រាយណាស់»។
5. ឧបករណ៍ប្រជាធិបតេយ្យ
Steve Newman ស្ថាបនិក និងជាប្រធានក្រុមហ៊ុន Scalyr៖ “ឧបករណ៍មិនគួរត្រូវបានលាក់ពីមនុស្សទេ ហើយពួកគេគួរតែងាយស្រួលរៀនសម្រាប់អ្នកដែលមានឆន្ទៈក្នុងការដាក់ពេលវេលា។ ប្រសិនបើសមត្ថភាពក្នុងការសួរកំណត់ហេតុត្រូវបានដាក់កម្រិតចំពោះមនុស្ស XNUMX នាក់ "បញ្ជាក់" ដើម្បីប្រើឧបករណ៍មួយ អ្នកនឹងតែងតែមានមនុស្សអតិបរមា XNUMX នាក់ដែលអាចរកបានដើម្បីដោះស្រាយបញ្ហា ទោះបីជាអ្នកមានបរិស្ថានកុំព្យូទ័រធំខ្លាំងក៏ដោយ។ ម្យ៉ាងវិញទៀត វាមានការជាប់គាំងនៅទីនេះ ដែលអាចនាំឱ្យមានផលវិបាកធ្ងន់ធ្ងរ (អាជីវកម្ម)»។
6. បង្កើតលក្ខខណ្ឌដ៏ល្អសម្រាប់ការងារជាក្រុម
លោក Tom Clark ប្រធានវេទិកាទូទៅនៅ ITV៖ “អ្នកអាចធ្វើអ្វីបាន ប៉ុន្តែមិនមែនអ្វីៗទាំងអស់ក្នុងពេលតែមួយនោះទេ។ ដូច្នេះ ចូរកំណត់គោលដៅធំ ចាប់ផ្តើមតូច ហើយឈានទៅមុខក្នុងការធ្វើម្តងទៀតយ៉ាងលឿន។ យូរៗទៅ អ្នកនឹងបង្កើតកេរ្តិ៍ឈ្មោះសម្រាប់ការសម្រេចកិច្ចការផ្សេងៗ ដូច្នេះអ្នកផ្សេងទៀតក៏ចង់ប្រើវិធីរបស់អ្នកផងដែរ។ ហើយកុំបារម្ភអំពីការកសាងក្រុមដែលមានប្រសិទ្ធភាពខ្ពស់។ ផ្ទុយទៅវិញ ការផ្តល់ឱ្យមនុស្សនូវលក្ខខណ្ឌការងារដ៏ល្អ និងប្រសិទ្ធភាពនឹងធ្វើតាម»។
7. កុំភ្លេចអំពីច្បាប់របស់ Conway និងក្រុមប្រឹក្សា Kanban
លោក Logan Daigle នាយកផ្នែកចែកចាយកម្មវិធី និងយុទ្ធសាស្រ្ត DevOps នៅ CollabNetVersionOne៖ “វាមានសារៈសំខាន់ណាស់ក្នុងការយល់ដឹងអំពីផលវិបាកនៃច្បាប់ Conway ។ នៅក្នុងពាក្យសំដីរលុងរបស់ខ្ញុំ ច្បាប់នេះចែងថាផលិតផលដែលយើងបង្កើត និងដំណើរការដែលយើងប្រើដើម្បីធ្វើដូច្នេះ រួមទាំង DevOps ប្រែទៅជាមានរចនាសម្ព័ន្ធដូចគ្នាទៅនឹងអង្គការរបស់យើងដែរ»។
"ប្រសិនបើមាន silos ច្រើននៅក្នុងអង្គការមួយ ហើយការគ្រប់គ្រងផ្លាស់ប្តូរដៃជាច្រើនដងនៅពេលរៀបចំផែនការ បង្កើត និងបញ្ចេញកម្មវិធី ឥទ្ធិពលនៃការធ្វើមាត្រដ្ឋាននឹងសូន្យ ឬមានរយៈពេលខ្លី។ ប្រសិនបើស្ថាប័នមួយបង្កើតក្រុមឆ្លងមុខងារជុំវិញផលិតផលដែលត្រូវបានផ្តល់មូលនិធិដោយផ្តោតលើទីផ្សារ នោះឱកាសនៃភាពជោគជ័យកើនឡើងយ៉ាងខ្លាំង។
"ទិដ្ឋភាពសំខាន់មួយទៀតនៃការធ្វើមាត្រដ្ឋានគឺដើម្បីបង្ហាញការងារទាំងអស់ដែលកំពុងដំណើរការ (WIP, workinprogress) នៅលើបន្ទះ Kanban ។ នៅពេលដែលអង្គការមានកន្លែងដែលមនុស្សអាចមើលឃើញវត្ថុទាំងនេះ វាជួយលើកទឹកចិត្តយ៉ាងខ្លាំងដល់ការសហការគ្នា ដែលមានឥទ្ធិពលវិជ្ជមានទៅលើការធ្វើមាត្រដ្ឋាន។
8. រកមើលស្លាកស្នាមចាស់
Manuel Pais អ្នកប្រឹក្សា DevOps និងជាសហអ្នកនិពន្ធនៃ Team Topologies៖ "ការទទួលយកការអនុវត្ត DevOps លើសពី Dev និង Ops ខ្លួនវា ហើយការព្យាយាមអនុវត្តពួកវាទៅមុខងារផ្សេងទៀតគឺស្ទើរតែជាវិធីសាស្រ្តដ៏ល្អប្រសើរ។ នេះពិតជានឹងមានផលប៉ះពាល់ខ្លះៗ (ឧទាហរណ៍ តាមរយៈការគ្រប់គ្រងដោយដៃដោយស្វ័យប្រវត្តិ) ប៉ុន្តែអាចសម្រេចបានច្រើនទៀត ប្រសិនបើយើងចាប់ផ្តើមជាមួយនឹងការយល់ដឹងអំពីដំណើរការចែកចាយ និងមតិកែលម្អ។
"ប្រសិនបើមានស្លាកស្នាមចាស់នៅក្នុងប្រព័ន្ធ IT របស់អង្គការ - នីតិវិធី និងយន្តការគ្រប់គ្រងដែលត្រូវបានអនុវត្តជាលទ្ធផលនៃឧប្បត្តិហេតុកាលពីអតីតកាល ប៉ុន្តែបានបាត់បង់ភាពពាក់ព័ន្ធរបស់ពួកគេ (ដោយសារតែការផ្លាស់ប្តូរផលិតផល បច្ចេកវិទ្យា ឬដំណើរការ) - បន្ទាប់មកពួកគេប្រាកដជាត្រូវដកចេញ។ ឬដំណើរការរលូន ជាជាងធ្វើឱ្យដំណើរការដែលគ្មានប្រសិទ្ធភាព ឬមិនចាំបាច់ដោយស្វ័យប្រវត្តិ។
9. កុំបង្កាត់ជម្រើស DevOps
លោក Anthony Edwards នាយកប្រតិបត្តិការនៅ Eggplant៖ “DevOps គឺជាពាក្យមិនច្បាស់លាស់ ដូច្នេះក្រុមនីមួយៗបញ្ចប់ជាមួយនឹងកំណែ DevOps ផ្ទាល់ខ្លួន។ ហើយមិនមានអ្វីអាក្រក់ជាងនេះទេនៅពេលដែលអង្គការមួយស្រាប់តែមាន DevOps ចំនួន 20 ប្រភេទដែលមិនទាក់ទងគ្នាបានល្អ។ វាមិនអាចទៅរួចទេដែលក្រុមអភិវឌ្ឍន៍នីមួយៗក្នុងចំណោមក្រុមអភិវឌ្ឍន៍ទាំងបីមានចំណុចប្រទាក់ពិសេសផ្ទាល់ខ្លួនរវាងការអភិវឌ្ឍន៍ និងការគ្រប់គ្រងផលិតផល។ ផលិតផលក៏មិនគួរមានការរំពឹងទុកតែមួយគត់របស់ពួកគេសម្រាប់ការគ្រប់គ្រងមតិកែលម្អនៅពេលផ្ទេរទៅម៉ាស៊ីនក្លែងធ្វើផលិតកម្ម។ បើមិនដូច្នោះទេ អ្នកនឹងមិនអាចធ្វើមាត្រដ្ឋាន DevOps បានទេ។
10. ផ្សព្វផ្សាយតម្លៃអាជីវកម្មរបស់ DevOps
Steve Newman ស្ថាបនិក និងជាប្រធានក្រុមហ៊ុន Scalyr៖ "ធ្វើការដើម្បីទទួលស្គាល់តម្លៃរបស់ DevOps ។ រៀន និងមានអារម្មណ៍សេរីដើម្បីនិយាយអំពីអត្ថប្រយោជន៍នៃអ្វីដែលអ្នកធ្វើ។ DevOps គឺជាកម្មវិធីសន្សំសំចៃពេលវេលា និងថវិកាដែលមិនគួរឱ្យជឿ (គ្រាន់តែគិតថា៖ ពេលវេលារងចាំតិច ពេលវេលាខ្លីជាងក្នុងការស្តារឡើងវិញ) ហើយក្រុម DevOps ត្រូវតែសង្កត់ធ្ងន់ដោយមិនចេះនឿយហត់ (និងផ្សព្វផ្សាយ) សារៈសំខាន់នៃគំនិតផ្តួចផ្តើមទាំងនេះចំពោះភាពជោគជ័យនៃអាជីវកម្ម។ វិធីនេះអ្នកអាចពង្រីករង្វង់អ្នកប្រកាន់ខ្ជាប់ និងបង្កើនឥទ្ធិពលរបស់ DevOps នៅក្នុងអង្គការ។"
ប្រាក់
នៅលើ DevOps ផ្ទាល់របស់យើងនឹងមកដល់នៅថ្ងៃទី 13 ខែកញ្ញា - បាទ Red Hat ក្នុងនាមជាអ្នកផលិតកម្មវិធី មានក្រុម និងការអនុវត្ត DevOps ផ្ទាល់ខ្លួន។
វិស្វកររបស់យើងគឺលោក Mark Birger ដែលបង្កើតសេវាកម្មស្វ័យប្រវត្តិកម្មផ្ទៃក្នុងសម្រាប់ក្រុមផ្សេងទៀតនៅទូទាំងអង្គការនឹងប្រាប់រឿងផ្ទាល់ខ្លួនរបស់គាត់ជាភាសារុស្សីសុទ្ធ - របៀបដែលក្រុម Red Hat DevOps បានផ្ទេរកម្មវិធីពីបរិយាកាសនិម្មិត Hat Virtualization ដែលគ្រប់គ្រងដោយ Ansible ទៅជាទម្រង់កុងតឺន័រពេញលេញនៅលើ វេទិកា OpenShift ។
ប៉ុន្តែនោះមិនមែនទាំងអស់ទេ៖
នៅពេលដែលអង្គការបានផ្លាស់ប្តូរបន្ទុកការងារទៅកុងតឺន័រ វិធីសាស្ត្រត្រួតពិនិត្យកម្មវិធីបែបប្រពៃណីប្រហែលជាមិនដំណើរការទេ។ នៅក្នុងសុន្ទរកថាទីពីរ យើងនឹងពន្យល់ពីការលើកទឹកចិត្តរបស់យើងសម្រាប់ការផ្លាស់ប្តូរវិធីដែលយើងកត់ត្រា និងបង្ហាញពីការបន្តនៃផ្លូវដែលនាំយើងទៅរកការកាប់ឈើទំនើប និងវិធីសាស្រ្តត្រួតពិនិត្យ។
ប្រភព: www.habr.com