ទិដ្ឋភាពទូទៅនៃសន្និសីទ DevOpsDays Moscow: ការយល់ដឹងពីរបាយការណ៍ចំនួន 6

សន្និសីទ​លើក​ទី​៣​បាន​ធ្វើ​ឡើង​នៅ​ថ្ងៃ​ទី​៧ ខែ​ធ្នូ DevOpsDays ទីក្រុងម៉ូស្គូរៀបចំដោយសហគមន៍ Moscow DevOps ដោយមានការគាំទ្រពី Mail.ru Cloud Solutions ។ បន្ថែមពីលើការធ្វើបទបង្ហាញដោយអ្នកអនុវត្ត DevOps ឈានមុខគេ អ្នកចូលរួមអាចចូលរួមការពិភាក្សាខ្លីៗ សិក្ខាសាលា និងការប្រាស្រ័យទាក់ទងគ្នានៅកន្លែងបើកចំហ។

យើងបានប្រមូលនូវការយល់ដឹងសំខាន់ៗពីសុន្ទរកថាចំនួនប្រាំមួយ ហើយបានធ្វើបទសម្ភាសន៍ជាមួយអ្នកនិយាយជាច្រើននាក់ ដើម្បីស្វែងរកអ្វីដែលបានបន្សល់ទុកនៅពីក្រោយរបាយការណ៍។

ខាងក្នុង៖

1. Baruch Sadogursky, JFrog: "អនុញ្ញាតឱ្យកម្មវិធីហូរចេញពីអ្នកលក់ទៅអ្នកប្រើប្រាស់ដូចជារាវ"
2. Pavel Selivanov, Southbridge: "Dev និង Ops មានភារកិច្ចរួមមួយ - ដើម្បីបង្កើតផលិតផលដែលដំណើរការ"
3. Vladimir Utratenko, X5 Retail Group: "DevOps នៅក្នុងសហគ្រាសគឺជាការអភិវឌ្ឍន៍ដោយគ្មានការឈឺចាប់និងភ្លើង"
4. Sergey Puzyrev, Facebook: "វិស្វករផលិតកម្មយកចិត្តទុកដាក់លើសេវាកម្មទាំងមូល: ដូច្នេះទាំងអ្នកប្រើប្រាស់និងអ្នកអភិវឌ្ឍន៍មានពេលវេលាល្អ"
5. Mikhail Chinkov, AMBOSS: "នាយកដ្ឋានមួយមិនអាចដើរតាមផ្លូវ DevOps បានទេ ក្រុមហ៊ុនទាំងមូលត្រូវតែដើរតាមវា"
6. អ្នកចូលចិត្ត DevOps នៃ Rosbank: "1000 ថ្ងៃដើម្បីអនុវត្ត DevOps នៅក្នុងសហគ្រាសបង្ហូរឈាម"

1. Baruch Sadogursky, JFrog: "អនុញ្ញាតឱ្យកម្មវិធីហូរចេញពីអ្នកលក់ទៅអ្នកប្រើប្រាស់ដូចជារាវ"

ការបរាជ័យក្នុងការអាប់ដេតកម្មវិធីកើតឡើងរៀងរាល់ម៉ោង និងសម្រាប់មនុស្សគ្រប់គ្នា។ នេះគ្រាន់តែជារឿងភ័យរន្ធត់មួយប៉ុណ្ណោះពីសុន្ទរកថា៖ Knight Capital បានបាត់បង់ $440 លានដុល្លារក្នុងរយៈពេលមួយម៉ោងបន្ទាប់ពីការអាប់ដេតមិនជោគជ័យ។

Baruch បាននិយាយអំពីគំរូ DevOps នៃការធ្វើបច្ចុប្បន្នភាពជាបន្តបន្ទាប់ដែលនឹងជួយជៀសវាងការបរាជ័យ និងការស្អប់អ្នកប្រើប្រាស់៖

ការវិលត្រឡប់មកវិញក្នុងស្រុក — រក្សាកំណែមុននៃកម្មវិធីនៅលើឧបករណ៍របស់អ្នកដើម្បីត្រលប់មកវិញប្រសិនបើមានអ្វីមួយកើតឡើង។ វា​នឹង​ការពារ​អ្នក​ប្រសិន​បើ​មាន​រឿង​អាក្រក់​ខ្លាំង​ដែល​អ្នក​មិន​អាច​ផ្ញើ​បំណះ​លើ​អាកាស។

ជុំវិញការអាប់ដេតតាមអាកាស - បន្តកាន់តែប្រសើរ។ បើមិនដូច្នេះទេ វានឹងដូចទៅនឹងអ្នកអភិវឌ្ឍន៍ Jaguar ដែរ៖ ដោយសារបញ្ហានៅក្នុងប្រព័ន្ធហ្វ្រាំង ដែលមិនអាចអាប់ដេតនៅលើអាកាស រថយន្តត្រូវប្រមូលមកវិញពីការលក់។ វា​ជា​ការ​ឈឺ​ចាប់ និង​មាន​តម្លៃ​ថ្លៃ។

ការធ្វើបច្ចុប្បន្នភាពជាបន្តបន្ទាប់ — ធ្វើបច្ចុប្បន្នភាពកម្មវិធីជាបន្តបន្ទាប់ ដរាបណាមុខងារថ្មីរួចរាល់។ ជាមួយនឹងការអាប់ដេតដ៏កម្រ លក្ខណៈពិសេសត្រូវបានដាក់ជាក្រុមជាមួយគ្នា ការអាប់ដេតដ៏សំខាន់អាចរង់ចាំសម្រាប់អ្វីដែលមិនសំខាន់។ ដូចនៅក្នុង Tesla ការអាប់ដេតដែលត្រូវបានគេសន្មត់ថាដើម្បីជួសជុលហ្វ្រាំងចៃដន្យកំពុងរង់ចាំការអាប់ដេតចំពោះហ្គេមអុក។

ការដាក់ពង្រាយដោយស្វ័យប្រវត្តិ - ជំនួសមនុស្សដោយម៉ាស៊ីន ព្រោះមនុស្សអាក្រក់ក្នុងការអនុវត្តសកម្មភាពប្រចាំថ្ងៃ

ការធ្វើបច្ចុប្បន្នភាពញឹកញាប់ - ជួយអ្នកបង្កើតទម្លាប់ និងកម្ចាត់ការភ័យខ្លាច។ ការអាប់ដេតដ៏កម្រប្រែទៅជាព្រឹត្តិការណ៍សង្គ្រោះបន្ទាន់។

ដឹងពីស្ថានភាពនៃឧបករណ៍ - សាកល្បងការធ្វើបច្ចុប្បន្នភាព មិនមែនការដំឡើងតាំងពីដំបូងឡើយ។ នេះមានសារៈសំខាន់ណាស់ ពីព្រោះការអាប់ដេតអាចមានឥរិយាបទខុសគ្នា អាស្រ័យលើស្ថានភាពរបស់ឧបករណ៍។

ការចេញផ្សាយ Canary — បញ្ចេញបច្ចុប្បន្នភាពទៅកាន់អ្នកប្រើប្រាស់មួយចំនួនតូច ហើយសង្កេត។ នេះកាត់បន្ថយការខូចខាតប្រសិនបើមានអ្វីមួយខុសប្រក្រតី។

ការអាប់ដេតដោយគ្មានភាពអាចរកបាន — អនុញ្ញាតឱ្យអតិថិជនសម្គាល់ឃើញតែមុខងារថ្មីៗប៉ុណ្ណោះ ហើយមិនត្រូវទុកចោលដោយគ្មានសេវាកម្មរយៈពេលជាច្រើនសប្តាហ៍ទេ ខណៈពេលដែលអ្នកចាប់ផ្តើមការអាប់ដេត។

យើងបានពិភាក្សាជាមួយ Baruch Sadogursky អំពីរបៀបដែលទស្សនៈនៅលើ DevOps ខុសគ្នានៅក្នុងភាសារុស្សី និងបស្ចិមប្រទេស ថាតើ Cloud នឹងធ្វើអ្វីៗគ្រប់យ៉ាងសម្រាប់យើងក្នុងពេលឆាប់ៗនេះ ហើយថាតើសេវាកម្មសូហ្វវែរទាំងអស់នឹងធ្លាក់ចូលទៅក្នុងគ្រោងការណ៍ aaS ដែរឬទេ - មើលបទសម្ភាសន៍៖

2. Pavel Selivanov, Southbridge: "Dev និង Ops មានភារកិច្ចរួមមួយ - បង្កើតផលិតផលដែលដំណើរការ"

ការអនុវត្ត Kubernetes នឹងមិនជួយសម្រេចបាន DevOps ទេ ហើយផ្ទុយទៅវិញ វាអាចបំបែកអ្វីៗទាំងអស់។ Pavel បានពន្យល់ថាហេតុអ្វីបានជាបច្ចេកវិទ្យា (សូម្បីតែត្រជាក់បំផុត) មិនអាចដោះស្រាយបញ្ហារបស់អ្នកទាំងអស់បាន៖

ភាពស្មុគស្មាញនៃគម្រោងបានផ្លាស់ប្តូរហួសពីកូដ. ពីមុនមានកម្មវិធីស្មុគ្រស្មាញ៖ អន្តរកម្មក្នុងគម្រោង និងការអភិវឌ្ឍន៍ស្មុគ្រស្មាញ ប៉ុន្តែរចនាសម្ព័ន្ធសាមញ្ញ - អ្នកគ្រប់គ្រងបានដាក់ពង្រាយវា អ្វីៗដំណើរការ។ យើងបានផ្លាស់ប្តូរទៅសេវាកម្មខ្នាតតូច៖ សេវាកម្មនីមួយៗគឺជាកម្មវិធីសាមញ្ញ ការទំនាក់ទំនងដោយប្រើពិធីការស្តង់ដារ និងការអភិវឌ្ឍន៍យ៉ាងឆាប់រហ័ស ប៉ុន្តែរចនាសម្ព័ន្ធគម្រោងកាន់តែស្មុគស្មាញ។ ភាពស្មុគស្មាញនៃគម្រោងដែលមានស្ថាបត្យកម្ម microservice មិនបានទៅណាទេ - វាបានផ្លាស់ប្តូរហួសពីកូដ។ ឥឡូវនេះវិស្វករ DevOps ទទួលខុសត្រូវចំពោះវា។

អ្នកអភិវឌ្ឍន៍មិនចង់បានការផ្លាស់ប្តូរទេ បន្ទាប់ពីអនុវត្ត DevOps. ជាលទ្ធផល លំហូរការងារជាមួយ Kubernetes បន្តមើលទៅដូចជាការបោះភារកិច្ចពី Dev ទៅ Ops លើជញ្ជាំងមួយ មិនមែនគ្រាន់តែជាការប្រៀបធៀបទេ - Git ក្លាយជាជញ្ជាំងបែបនេះ។ អ្នកអភិវឌ្ឍន៍ដាក់កូដនៅទីនោះ ហើយដំណើរការដូចពីមុន ហើយអ្នកគ្រប់គ្រងមាន Kubernetes, CI/CD និងអ្វីៗផ្សេងទៀត។

ទោះយ៉ាងណាក៏ដោយ អ្នកអភិវឌ្ឍន៍ត្រូវទទួលយកការផ្លាស់ប្តូរ. ស្ថានភាពដែលអ្នកអភិវឌ្ឍន៍មិនដឹងថាអ្នកគ្រប់គ្រងកំពុងធ្វើអ្វី ហើយអ្នកគ្រប់គ្រងមិនដឹងថាមានអ្វីកើតឡើងជាមួយអ្នកអភិវឌ្ឍន៍ បង្កើតបញ្ហា។

ប្រសិនបើគ្មានអ្វីផ្លាស់ប្តូរសម្រាប់អ្នកអភិវឌ្ឍន៍ទេ ពួកគេមិនយល់ថាប្រតិបត្តិការនៃកម្មវិធីគឺជាការទទួលខុសត្រូវរបស់ពួកគេទេ - ល្បិចបច្ចេកទេសផ្សេងៗនឹងមិនដំណើរការទេ។

ជាមួយនឹងវត្តមានរបស់ DevOps និង Kubernetes ការអភិវឌ្ឍន៍ជាច្រើននឹងផ្លាស់ប្តូរ។ Devs ត្រូវតែមានជំនាញក្នុង Ops និងផ្ទុយមកវិញ។ អ្នកឯកទេសទាំងនេះមានជំនាញជាក់លាក់រៀងៗខ្លួន ប៉ុន្តែពួកគេត្រូវតែដឹងពីការងាររបស់គ្នាទៅវិញទៅមក។ Dev និង Ops ត្រូវតែធ្វើជាមិត្តមុនពេលអនុវត្ត Kubernetes បើមិនដូច្នេះទេ អ្នកនឹងបំបែកអ្វីដែលអ្នកមាន។

Pavel Selivanov និយាយអំពីអ្វីដែលនឹងកើតឡើងចំពោះ Kubernetes ក្នុងរយៈពេល 5 ឆ្នាំ និងអ្វីដែលការចាប់ផ្តើមទំនើបគួរបង្កើតជង់បច្ចេកវិទ្យា - មើលបទសម្ភាសន៍៖

3. Vladimir Utratenko, X5 Retail Group: "DevOps in Enterprise គឺជាការអភិវឌ្ឍន៍ដោយគ្មានការឈឺចាប់និងភ្លើង"

ក្រុមហ៊ុនមកដល់ការផ្លាស់ប្តូរ DevOps នៅពេលដែលពួកគេដឹងថាការអភិវឌ្ឍន៍យឺតពេក ហើយមិនបំពេញតាមការពិត ពួកគេមានបំណងចង់អភិវឌ្ឍឱ្យកាន់តែប្រសើរឡើង និងដំណើរការលឿនជាងមុន។

វ្ល៉ាឌីមៀ ពន្យល់ពីរបៀបដែលរឿងនេះកើតឡើង និងអ្វីដែលចាប់បាន៖

1. ដំបូងក្រុមហ៊ុនជួលវិស្វករ DevOps ។ នេះគឺជាអ្នកគ្រប់គ្រងប្រព័ន្ធជាន់ខ្ពស់ គាត់ចូលរួមក្នុងការដាក់ពង្រាយការចេញផ្សាយទៅកាន់ផលិតកម្ម ការកំណត់ស្តង់ដារនៃបរិយាកាសអភិវឌ្ឍន៍ ការរៀបចំហេដ្ឋារចនាសម្ព័ន្ធ ការរកឃើញ និងការដោះស្រាយបញ្ហាផ្សេងៗ ដំណើរការស្វ័យប្រវត្តិកម្ម និងការងារបច្ចេកទេសផ្សេងទៀត។
2. បន្ទាប់មកវិស្វករ DevOps ម្នាក់លែងគ្រប់គ្រាន់ហើយ ក្រុមហ៊ុនបានជួលក្រុម DevOps ។ នេះគឺជាមជ្ឈមណ្ឌលជំនាញដែលរៀបចំកិច្ចខិតខំប្រឹងប្រែងរបស់វិស្វករដែលមានភាពខុសគ្នា និងអនុញ្ញាតឱ្យពួកគេប្រមូលផ្តុំក្នុងទិសដៅតែមួយ។
3. តាមពិត វិស្វករ DevOps និងក្រុម DevOps គឺជាអ្នកប្រឆាំងគំរូនៃការផ្លាស់ប្តូរ DevOps ។ ដោយសារ DevOps និយាយអំពីការអនុវត្ត និងវប្បធម៌ លើសពីនេះ មានការអនុវត្តន៍ DevOps នៅក្នុងក្រុមហ៊ុនបច្ចេកវិទ្យា (SRE, Production Engineering)។

អ្វី​ដែល​ត្រូវធ្វើ? ជួលក្រុម DevOps បណ្តោះអាសន្ន ដែលនឹងជួយអនុវត្តការផ្លាស់ប្តូរ DevOps អនុវត្តការអនុវត្ត បណ្តុះវប្បធម៌អភិវឌ្ឍន៍ និងវប្បធម៌បច្ចេកវិទ្យា។

នៅពេលដែលអាជីវកម្មចូលមកលេង និងវិនិយោគនៅក្នុង DevOps សេណារីយ៉ូជាច្រើនអាចធ្វើទៅបាន៖ អ្វីៗនឹងធ្លាក់ចុះដាច់ពីគ្នានៅពេលហោះឡើង។ នឹងនៅតែជា SRE/Production Engineering ឬ Embedded Ops; នឹងផ្លាស់ទីទៅ BizOps នៅពេលដែលដំណើរការត្រូវបានផ្អែកលើរង្វាស់អាជីវកម្ម។

Vladimir Utratenko បានប្រាប់យើងអំពីរបៀបដែល "បង្ហូរឈាម" DevOps នៅក្នុងសហគ្រាសពិតជានិងរបៀបដែលការអនុវត្តត្រូវបានអនុវត្តនៅក្នុងការលក់រាយធំ - មើលបទសម្ភាសន៍:

4. Sergey Puzyrev, Facebook: "Production Engineer យកចិត្តទុកដាក់លើសេវាកម្មទាំងមូល៖ ដូច្នេះទាំងអ្នកប្រើប្រាស់ និងអ្នកអភិវឌ្ឍន៍មានពេលវេលាល្អ"

Facebook គឺជាក្រុមហ៊ុនដ៏ធំមួយ ដែលមានធាតុផ្សំជាច្រើន ម៉ាស៊ីនមេ មនុស្ស និងមជ្ឈមណ្ឌលទិន្នន័យ។ ទោះបីជាមានទំហំធំក៏ដោយ វាមានល្បឿនលឿនណាស់ - អ្នកអភិវឌ្ឍន៍អាចចាប់ផ្តើមសេវាកម្មជាច្រើនដងក្នុងមួយថ្ងៃ។ ម្យ៉ាងវិញទៀត Facebook កំពុងរីកចម្រើនយ៉ាងឆាប់រហ័ស ហើយវាមិនត្រឹមតែចំនួនអ្នកប្រើប្រាស់ និងម៉ាស៊ីនមេដែលកំពុងកើនឡើងប៉ុណ្ណោះទេ ចំនួនអ្នកអភិវឌ្ឍន៍ក៏កើនឡើងផងដែរ ដែលធ្វើឲ្យដំណើរការកាន់តែស្មុគស្មាញ។

Sergey បានប្រាប់ពីអ្វីដែលវិស្វករផលិតកម្មធ្វើនៅលើ Facebook៖

1. វិស្វករផលិតកម្មសរសេរកូដច្រើន គាត់ត្រូវតែមានចំណេះដឹងអំពីប្រព័ន្ធ៖ ប្រព័ន្ធប្រតិបត្តិការ ប្រព័ន្ធឯកសារ មូលដ្ឋានទិន្នន័យ បណ្តាញ និងអ្វីៗផ្សេងទៀត។ ត្រូវតែមានបទពិសោធន៍ធ្វើការជាមួយប្រព័ន្ធចែកចាយ និងវិស្វកម្មភាពជឿជាក់ ពោលគឺគាំទ្រភាពជឿជាក់នៃផលិតផល។ វាត្រូវតែនៅលើការហៅទូរសព្ទ ពោលគឺអាចហៅបានគ្រប់ពេល។
2. វិស្វករផលិតកម្មខុសគ្នាពីវិស្វករកម្មវិធីដែលមានជំនាញកម្រិតខ្ពស់ក្នុងប្រតិបត្តិការ ប៉ុន្តែតាមពិតទៅគឺជាប្រភេទរងនៃវិស្វករកម្មវិធី។ វិស្វករកម្មវិធីសរសេរកូដបន្ថែមទៀត ពួកគេអាចមានជំនាញបន្ថែមទាក់ទងនឹងការដំណើរការទិន្នន័យ។ នៅលើ Facebook អ្នកឯកទេសបែបនេះក៏ត្រូវតែហៅផងដែរ ដែលកើតឡើងជាការភ្ញាក់ផ្អើលមិនល្អសម្រាប់មនុស្សជាច្រើន។
3. សាជីជ្រុងនៃតម្រូវការរបស់វិស្វករផលិតកម្មនៅក្នុងក្រុមហ៊ុនមួយចាប់ផ្តើមជាមួយនឹងការត្រួតពិនិត្យម៉ាស៊ីនមេ និងវដ្តជីវិតរបស់ពួកគេ ពោលគឺការទទួលបានផ្នែករឹងថ្មី រៀបចំវា ដាក់វាឱ្យដំណើរការ។ កម្រិតបន្ទាប់គឺដូចគ្នានៅកម្រិតសេវាកម្ម៖ សេវាត្រួតពិនិត្យ និងវដ្តជីវិតរបស់ពួកគេ។ បន្ទាប់មកមក ការធ្វើមាត្រដ្ឋានគ្មានថ្នេរ និងការត្រួតពិនិត្យកម្រិតខ្ពស់។ ពួកគេប្តូរទៅការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិបន្ទាប់ពីវដ្តជីវិតសេវាកម្មត្រូវបានស្វ័យប្រវត្តិ។ ហើយនៅទីបញ្ចប់ ចាំបាច់ត្រូវធ្វើការកែតម្រូវដើម្បីឱ្យការធ្វើមាត្រដ្ឋានមានប្រសិទ្ធភាព ហើយក្រុមហ៊ុនសន្សំប្រាក់ និងធនធាន។

5. Mikhail Chinkov, AMBOSS: "នាយកដ្ឋានមួយមិនអាចដើរតាម DevOps បានទេ ក្រុមហ៊ុនទាំងមូលត្រូវតែដើរតាមវា"

Mikhail ជឿជាក់ថា DevOps គឺជាការអភិវឌ្ឍន៍ជាបន្តបន្ទាប់។ អ្នកមិនអាចណែនាំឧបករណ៍មួយចំនួន ហើយឈប់នៅទីនោះបានទេ។ តើបញ្ហាអ្វីខ្លះដែលរារាំងក្រុមហ៊ុនមិនឱ្យក្លាយជា DevOps និងរបៀបអនុវត្តការអនុវត្ត?

ភាពខុសគ្នាក្នុងការយល់ដឹង DevOps. ម្នាលភិក្ខុ​ទាំងឡាយ អ្នក​ផ្សាយ​សាសនា​ឃើញ​ហើយ អាស្រ័យ​លើ​សសរ ៥ យ៉ាង៖

• វប្បធម៌ - ផ្តោតលើមនុស្សនិងការសហការ;
• ស្វ័យប្រវត្តិកម្ម - ប្រតិភូកម្មទម្លាប់ទៅលំហូរការងារ;
• គ្មានខ្លាញ់ - ការសង្កត់ធ្ងន់លើការផ្តល់តម្លៃដល់អ្នកប្រើប្រាស់;
• ការចែករំលែក - ការផ្លាស់ប្តូរចំណេះដឹងជាបន្តបន្ទាប់;
• ម៉ែត្រ និងទទួលមតិកែលម្អដោយប្រើពួកវា។

ក្រុមហ៊ុនជាធម្មតាផ្តោតតែលើស្វ័យប្រវត្តិកម្ម និងការផ្តល់តម្លៃដល់អ្នកប្រើប្រាស់។ ប៉ុន្តែវប្បធម៌ ការចែករំលែកចំណេះដឹង និងឧបករណ៍វាស់ស្ទង់ DevOps ដើម្បីតាមដានការអភិវឌ្ឍន៍ធ្លាក់ចុះទៅក្នុងផ្ទៃខាងក្រោយ។

បញ្ហាប្រឈមស្តង់ដារ DevOps. គោលដៅផលិតផលគឺខុសគ្នាសម្រាប់ក្រុមហ៊ុនទាំងអស់ ហើយមិនអាចកំណត់ស្តង់ដារបានទេ។ ស្ថានភាពនៃ DevOps នៅក្នុងក្រុមហ៊ុនមួយអាស្រ័យលើក្រុមហ៊ុនខ្លួនឯង ប៉ុន្តែមនុស្សជាច្រើនមិនយល់ពីរឿងនេះ ហើយជឿថាវាគ្រប់គ្រាន់ក្នុងការជួលវិស្វករ DevOps ។

ហេតុអ្វីបានជាយើងមិនទាន់ DevOps? មានបញ្ហាសំខាន់ពីរ។ នៅក្នុងសហគ្រាសមានការអភិវឌ្ឍន៍យឺតនៃអង្គការ ការលំបាកក្នុងការផ្លាស់ប្តូរវ៉ិចទ័រនៅក្នុងគំនិតរបស់បុគ្គលិករាប់ពាន់នាក់។ ក្នុងការចាប់ផ្ដើមអាជីវកម្ម មានការខ្វះខាតប្រភពចំណេះដឹង និងបញ្ហាក្នុងការបែងចែកធនធានសម្រាប់ការផ្លាស់ប្តូរ។

ដំណាក់កាលនៃការអភិវឌ្ឍន៍ DevOps នៅក្នុងក្រុមហ៊ុនមួយ។:

• ទីមួយគឺហេដ្ឋារចនាសម្ព័ន្ធនៅក្នុងពពក ប៉ុន្តែគ្មាននរណាម្នាក់ដឹងពីរបៀបដែលវាដំណើរការនោះទេ លើកលែងតែអ្នកគ្រប់គ្រងម្នាក់ ឬពីរនាក់ប៉ុណ្ណោះ។
• ទីពីរ ហេដ្ឋារចនាសម្ព័ន្ធមានតម្លាភាព និងអាចយល់បានចំពោះវិស្វករទាំងអស់ ប៉ុន្តែដំណើរការមិនត្រូវបានសម្រួល។
• ទីបី - វិស្វករបើកដំណើរការ និងជួសជុលសេវាកម្មបន្តផ្ទាល់ដោយឯករាជ្យ។
• ទីបួន - វិស្វករជាជម្រើសនឹងរួមចំណែកដល់ហេដ្ឋារចនាសម្ព័ន្ធស្នូល កូដតម្លាភាពក្នុងពពក ការដាក់ពង្រាយដោយប៊ូតុង។

គ្រោងការណ៍ដ៏ល្អគឺអ្នកគ្រប់គ្នាមានសិទ្ធិចូលប្រើប្រាស់ហេដ្ឋារចនាសម្ព័ន្ធដូចគ្នា វិស្វករទាំងអស់មានសិទ្ធិប្រើប្រាស់ផលិតផល និងយល់ពីអ្វីដែលពួកគេកំពុងធ្វើ។

ដោយបានបិទទ្វារវប្បធម៌ និងបច្ចេកទេសទាំងអស់ ការផ្លាស់ប្តូរ DevOps របស់ក្រុមហ៊ុននឹងគិតគូរពីមតិកែលម្អពីធុរកិច្ច និងរង្វាស់វេទិកា។

6. អ្នកចូលចិត្ត DevOps នៃ Rosbank: "1000 ថ្ងៃដើម្បីអនុវត្ត DevOps នៅក្នុងសហគ្រាសបង្ហូរឈាម"

Yuri Bulich, Dina Maltseva, Evgeny Pankov មកពី Rosbank បានប្រាប់ពីរបៀបដែលពួកគេមក DevOps ក្នុងរយៈពេលបីឆ្នាំ។ មានគោលដៅពីរ៖ ដើម្បីដោះស្រាយបញ្ហាជាក់លាក់នៅក្នុងក្រុមជាក់លាក់ និងអនុវត្តឧបករណ៍កណ្តាល។

នេះគឺជាលទ្ធផលដែលសម្រេចបាន៖

លទ្ធផលសម្រាប់ក្រុមផលិតផល៖ ការជួបប្រជុំគ្នាលឿនជាង 30 ដង ការដំឡើងលឿនជាង 6 ដង ការសន្សំរហូតដល់ 30% នៅលើវដ្តពេញលេញ។ ឥឡូវនេះយើងមានសមត្ថភាពក្នុងការចុចប៊ូតុងមួយដើម្បីទៅកាន់ផលិតភាព

លទ្ធផលសម្រាប់ពាក្យបញ្ជាវេទិកា៖ ការដំឡើង និងដំឡើងលឿនជាង 10 ដង ការកើនឡើងចំនួនការដំឡើង 87% ការគ្របដណ្តប់ដោយស្វ័យប្រវត្តិ 46% ។ ក្រុមសមាហរណកម្មមិនមែនជាឧបសគ្គទៀតទេ

ដូច្នេះតើធ្វើដូចម្តេចដើម្បីអនុវត្តការអនុវត្ត DevOps នៅក្នុងសហគ្រាសបង្ហូរឈាម?

ដំបូងអនុវត្តគម្រោងសាកល្បង៖ ជ្រើសរើសក្រុម សម្រេចចិត្តពីរបៀបអនុវត្តស្ថាបត្យកម្ម និងជ្រើសរើសឧបករណ៍។ យើងបានជ្រើសរើសឧបករណ៍ដែលមានអាជ្ញាប័ណ្ណបើកចំហ ជាមួយនឹងការដំឡើងនៅក្នុងធនាគារ និងជំនាញក្នុងការធ្វើការជាមួយពួកគេ។ Rosbank ក្នុងពេលដំណាលគ្នាដាក់ពង្រាយពពកឯកជនរួមជាមួយវេទិកា DevOps ហើយវាបានជួយនៅពេលចាប់ផ្តើម។ នៅក្នុងពពក វាអាចទទួលបានធនធានចាំបាច់នៅពេលប៉ះប៊ូតុងមួយក្នុងរយៈពេល 15 នាទីពីមុន ដំណើរការបែបនេះអាចចំណាយពេលមួយសប្តាហ៍។

នៅក្នុងធនាគារ និងសហគ្រាសផ្សេងទៀត ចាំបាច់ត្រូវធ្វើការរឹតបន្តឹងជាមុនជាមួយក្រុមសន្តិសុខព័ត៌មាន និងស្វែងរកដំណោះស្រាយដែលនឹងអនុញ្ញាតឱ្យមានការផ្លាស់ប្តូរត្រូវបានអនុវត្ត។

បន្ទាប់​ពី​អ្នក​បើក​យន្តហោះ ដំណោះស្រាយ​ដែល​ជោគជ័យ​ត្រូវ​ធ្វើ​ការ​ពង្រីក.

1. វាមានសារៈសំខាន់ណាស់ក្នុងការ "តម្រង់" បំពង់បង្ហូរប្រេងឱ្យបានច្រើនតាមដែលអាចធ្វើទៅបាន លុបបំបាត់តំណភ្ជាប់ដែលមិនចាំបាច់ចេញពីវា ការបន្លិចអ្នកផ្តល់តម្លៃ និងដកចេញនូវសមាសធាតុដែលនៅសល់។ អន្តរការីគឺជាអ្នកប្រឆាំងគំរូ។ ជាឧទាហរណ៍ នៅ Rosbank ក្រុមមួយចំនួនមិនបានបង្កើតការអភិវឌ្ឍន៍ផ្ទៃក្នុងទេ ដោយបន្សល់ទុកតែការអភិវឌ្ឍន៍ខាងក្រៅប៉ុណ្ណោះ។ នេះនាំទៅដល់ការលេចចេញនូវក្រុម DevOps ដែលយកចិត្តទុកដាក់ ដែលធានាការផ្ទេរកូដពីខាងក្រៅទៅអ្នកអភិវឌ្ឍន៍ខាងក្នុង។ បញ្ហាត្រូវបានដោះស្រាយដោយការរួមបញ្ចូលការអភិវឌ្ឍន៍ខាងក្រៅទៅក្នុង CI/CD ដូច្នេះពួកគេនឹងមិនត្រឹមតែផ្ទេរលេខកូដពីខ្លួនទៅធនាគារប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងទទួលខុសត្រូវចំពោះភាពជោគជ័យរបស់វាផងដែរ។
2. គំរូនៃភាពចាស់ទុំរួមមានធាតុផ្សំនៃការអនុវត្ត DevOps ឧបករណ៍ដែលបានរាយបញ្ជី ហើយបានគិតគូរពីលក្ខណៈពិសេសនៃការធ្វើការជាមួយអ្នកផ្គត់ផ្គង់ខាងក្រៅ - នៅពេលអនាគត វាបានជួយកាត់បន្ថយការយឺតយ៉ាវនៃកិច្ចការនៅពេលអនុវត្តពួកវាក្នុងក្រុមថ្មី។
3. យើងត្រូវការអភិបាលកិច្ចក្នុងទម្រង់នៃការគ្រប់គ្រងទន់ និងអនុសាសន៍។ សៀវភៅណែនាំ DevOps ដែលដំណើរការបានល្អគឺជាសំណុំនៃលក្ខណៈរៀបចំ និងឧបករណ៍ដែលជួយក្រុមឱ្យប្រើវេទិកាបានត្រឹមត្រូវ។
4. អ្នកគួរតែយកចិត្តទុកដាក់ភ្លាមៗចំពោះវប្បធម៌ បន្ទាប់មកការផ្លាស់ប្តូរជាច្រើននឹងកើតឡើងលឿន និងងាយស្រួលជាង។ ពង្រីកសហគមន៍ផ្ទៃក្នុងរបស់អ្នក ធ្វើការប្រជុំ សិក្ខាសាលាបច្ចេកទេស វគ្គបណ្តុះបណ្តាល និងសកម្មភាពសប្បាយៗ។ នេះបង្កើតផល៖ មនុស្សចែករំលែកការអនុវត្ត មើលថាអ្នកណាធ្វើអ្វី ដឹងពីកន្លែងដែលត្រូវបង្វែរ មានការឃោសនាបំផ្លើស និងការប្រកួតប្រជែងដែលមានសុខភាពល្អនៅក្នុងក្រុមហ៊ុន។
5. វាគ្មានន័យទេក្នុងការធ្វើការជាមួយអ្នកដែលមិនចូលរួមក្នុងដំណើរការនេះ ជាមួយនឹងក្រុមដែលមិនទាន់ចាស់ទុំ វាជាការប្រសើរជាងក្នុងការវិនិយោគលើក្រុមដែលចាប់អារម្មណ៍ និងមនុស្សដែលស្មោះត្រង់។
6. ដំណោះស្រាយដែលបានជ្រើសរើសត្រូវតែមានភាពងាយស្រួលសម្រាប់វិស្វករទាំងនោះដែលប្រើវា។
7. ការអភិវឌ្ឍន៍ខាងក្រៅមិនមែនជាការរារាំងទេ ការអនុវត្តក៏អាចត្រូវបានអនុវត្តនៅទីនោះដែរ រឿងសំខាន់គឺថាក្រុមខ្លួនឯងមានបំណងប្រាថ្នា។

អត្ថប្រយោជន៍បន្តិចទៀត។

បញ្ជីសៀវភៅដែលគួរអានសម្រាប់អ្នកនៅក្នុង DevOps ពី Alexander Chistyakov, vdsina.ru:

1. Irina Yakutenko "ឆន្ទៈនិងការគ្រប់គ្រងខ្លួនឯង" ។
2. Daniel Kahneman "ការគិតលឿននិងយឺត" ។
3. Barbara Oakley "ចិត្តសម្រាប់លេខ" ។
4. Maxim Dorofeev "បច្ចេកទេស Jedi" ។
5. Viktor Frankl "ការស្វែងរកអត្ថន័យរបស់មនុស្ស" ។

ចាំមើល

យើងក៏ស្រលាញ់ DevOps ដែរ។ អនុវត្តតាមការប្រកាសស៊េរី @DevOps និង @Kubernetes ក៏ដូចជាព្រឹត្តិការណ៍ Mail.ru Cloud Solutions ផ្សេងទៀតនៅក្នុងឆានែល Telegram របស់យើង៖ t.me/k8s_mail

ប្រភព: www.habr.com