ស្ថាបត្យកម្មផ្លាស់ប្តូរប្រាំពីរដោយផ្អែកលើគោលការណ៍ DevOps

សំណួរ "របៀបអនុវត្ត devops" មានច្រើនឆ្នាំមកហើយ ប៉ុន្តែមិនមានសម្ភារៈល្អច្រើនទេ។ ពេលខ្លះអ្នកធ្លាក់ខ្លួនជាជនរងគ្រោះដោយការផ្សាយពាណិជ្ជកម្មពីអ្នកប្រឹក្សាដែលមិនសូវឆ្លាតដែលត្រូវការលក់ពេលវេលារបស់ពួកគេ មិនថាយ៉ាងណានោះទេ។ ពេលខ្លះ ទាំងនេះជាពាក្យមិនច្បាស់លាស់ ដែលជាទូទៅនិយាយអំពីរបៀបដែលកប៉ាល់នៃក្រុមហ៊ុនមេហ្គា វាយលុកការពង្រីកនៃសកលលោក។ សំណួរកើតឡើង៖ តើនេះជាអ្វីសម្រាប់យើង? អ្នកនិពន្ធជាទីគោរព តើអ្នកអាចបង្កើតគំនិតរបស់អ្នកយ៉ាងច្បាស់នៅក្នុងបញ្ជីបានទេ?

ទាំងអស់នេះកើតចេញពីការពិតដែលថាមិនមានការអនុវត្តជាក់ស្តែងច្រើន និងការយល់ដឹងអំពីលទ្ធផលនៃការផ្លាស់ប្តូរនៃវប្បធម៌របស់ក្រុមហ៊ុនបានប្រមូលផ្តុំ។ ការផ្លាស់ប្តូរវប្បធម៌គឺជារឿងយូរអង្វែង លទ្ធផលដែលនឹងមិនបង្ហាញក្នុងមួយសប្តាហ៍ ឬមួយខែ។ យើងត្រូវការនរណាម្នាក់ដែលមានអាយុគ្រប់គ្រាន់ដើម្បីមើលពីរបៀបដែលក្រុមហ៊ុនត្រូវបានសាងសង់ និងបរាជ័យក្នុងរយៈពេលជាច្រើនឆ្នាំ។

លោក John Willis - ឪពុកម្នាក់របស់ DevOps ។ លោក John មានបទពិសោធន៍ជាច្រើនទសវត្សរ៍ក្នុងការធ្វើការជាមួយក្រុមហ៊ុនមួយចំនួនធំ។ ថ្មីៗ​នេះ ចន​បាន​ចាប់​ផ្ដើម​សម្គាល់​ឃើញ​គំរូ​ជាក់​លាក់​ដែល​កើត​ឡើង​ពេល​ធ្វើ​ការ​ជាមួយ​ពួកគេ​ម្នាក់ៗ។ ដោយប្រើ archetypes ទាំងនេះ John ណែនាំក្រុមហ៊ុនលើផ្លូវពិតនៃការផ្លាស់ប្តូរ DevOps ។ សូមអានបន្ថែមអំពី archetypes ទាំងនេះនៅក្នុងការបកប្រែរបាយការណ៍របស់គាត់ពីសន្និសីទ DevOops 2018 ។

អំពីអ្នកនិយាយ៖

ជាង 35 ឆ្នាំនៅក្នុងការគ្រប់គ្រង IT ដែលបានចូលរួមក្នុងការបង្កើតអ្នកកាន់តំណែងមុននៃ OpenCloud នៅ Canonical បានចូលរួមក្នុងការចាប់ផ្ដើមអាជីវកម្មចំនួន 10 ដែលពីរត្រូវបានលក់ទៅឱ្យ Dell និង Docker ។ បច្ចុប្បន្នគាត់ជាអនុប្រធាន DevOps និង Digital Practices នៅ SJ Technologies។

បន្ទាប់​គឺ​ជា​រឿង​តាម​ទស្សនៈ​របស់​ចន។

ឈ្មោះរបស់ខ្ញុំគឺ John Willis ហើយកន្លែងដែលងាយស្រួលបំផុតក្នុងការស្វែងរកខ្ញុំគឺនៅលើ Twitter, @botchagalupe. ខ្ញុំមានឈ្មោះក្លែងក្លាយដូចគ្នានៅលើ Gmail និង GitHub ។ ក поэтойссылке អ្នកអាចស្វែងរកការថតវីដេអូនៃរបាយការណ៍ និងបទបង្ហាញរបស់ខ្ញុំសម្រាប់ពួកគេ។

ខ្ញុំមានកិច្ចប្រជុំជាច្រើនជាមួយ CIO នៃក្រុមហ៊ុនធំៗជាច្រើន។ ជារឿយៗពួកគេត្អូញត្អែរថាពួកគេមិនយល់ថា DevOps ជាអ្វីទេ ហើយអ្នកគ្រប់គ្នាដែលព្យាយាមពន្យល់វាប្រាប់ពួកគេកំពុងនិយាយអំពីអ្វីដែលប្លែក។ ការត្អូញត្អែរទូទៅមួយទៀតគឺថា DevOps មិនដំណើរការទេ ទោះបីជាវាហាក់បីដូចជាអ្នកដឹកនាំកំពុងធ្វើអ្វីគ្រប់យ៉ាងដូចដែលបានពន្យល់ដល់ពួកគេ។ យើងកំពុងនិយាយអំពីក្រុមហ៊ុនធំៗដែលមានអាយុកាលជាងមួយរយឆ្នាំ។ បន្ទាប់ពីនិយាយជាមួយពួកគេ ខ្ញុំបានសន្និដ្ឋានថាសម្រាប់បញ្ហាជាច្រើន វាមិនមែនជាបច្ចេកវិទ្យាខ្ពស់ដែលសមស្របបំផុតនោះទេ ប៉ុន្តែជាដំណោះស្រាយដែលមានបច្ចេកវិទ្យាទាប។ ជាច្រើនសប្តាហ៍ ខ្ញុំទើបតែបាននិយាយជាមួយមនុស្សមកពីនាយកដ្ឋានផ្សេងៗ។ អ្វី​ដែល​អ្នក​ឃើញ​នៅ​ក្នុង​រូបភាព​ដំបូង​បំផុត​ក្នុង​ការ​ប្រកាស​គឺ​ជា​គម្រោង​ចុង​ក្រោយ​របស់​ខ្ញុំ​នេះ​គឺ​ជា​អ្វី​ដែល​បន្ទប់​មើល​ទៅ​ដូច​ជា​បន្ទាប់​ពី​ការ​ធ្វើ​ការ​បី​ថ្ងៃ​។

តើ DevOps ជាអ្វី?

ជាការពិតណាស់ ប្រសិនបើអ្នកសួរមនុស្ស 10 នាក់ ពួកគេនឹងផ្តល់ចម្លើយ 10 ផ្សេងគ្នា។ ប៉ុន្តែនេះគឺជាអ្វីដែលគួរឱ្យចាប់អារម្មណ៍: ចម្លើយទាំងដប់នេះនឹងត្រឹមត្រូវ។ មិនមានចម្លើយខុសនៅទីនេះទេ។ ខ្ញុំបានចូលជ្រៅក្នុង DevOps ប្រហែល 10 ឆ្នាំ ហើយជាជនជាតិអាមេរិកដំបូងគេនៅ DevOpsDay ដំបូង។ ខ្ញុំនឹងមិននិយាយថាខ្ញុំឆ្លាតជាងអ្នកគ្រប់គ្នាដែលចូលរួមក្នុង DevOps នោះទេ ប៉ុន្តែកម្រមានអ្នកណាម្នាក់ដែលបានចំណាយលើការខិតខំប្រឹងប្រែងច្រើនណាស់។ ខ្ញុំជឿថា DevOps កើតឡើងនៅពេលដែលធនធានមនុស្ស និងបច្ចេកវិទ្យាមកជាមួយគ្នា។ យើងច្រើនតែភ្លេចអំពីវិមាត្ររបស់មនុស្ស ទោះបីជាយើងនិយាយច្រើនអំពីវប្បធម៌គ្រប់ប្រភេទក៏ដោយ។

ឥឡូវនេះយើងមានទិន្នន័យជាច្រើន ការស្រាវជ្រាវសិក្សារយៈពេល 2000 ឆ្នាំ ការធ្វើតេស្តទ្រឹស្តីលើមាត្រដ្ឋានឧស្សាហកម្ម។ អ្វី​ដែល​ការ​សិក្សា​ទាំង​នេះ​ប្រាប់​យើង​គឺ​ថា ប្រសិន​បើ​អ្នក​រួម​បញ្ចូល​គំរូ​អាកប្បកិរិយា​មួយ​ចំនួន​ក្នុង​វប្បធម៌​ស្ថាប័ន​មួយ អ្នក​អាច​សម្រេច​បាន​ការ​បង្កើន​ល្បឿន 5000x ។ ការបង្កើនល្បឿននេះត្រូវបានផ្គូផ្គងដោយការធ្វើឱ្យប្រសើរឡើងស្មើគ្នានៅក្នុងស្ថេរភាព។ នេះគឺជាការវាស់វែងជាបរិមាណនៃអត្ថប្រយោជន៍ដែល DevOps អាចនាំយកទៅឱ្យក្រុមហ៊ុនណាមួយ។ កាលពីប៉ុន្មានឆ្នាំមុន ខ្ញុំកំពុងនិយាយអំពី DevOps ទៅកាន់ CEO នៃក្រុមហ៊ុន Fortune 5 នៅពេលដែលខ្ញុំកំពុងរៀបចំបទបង្ហាញ ខ្ញុំភ័យខ្លាំងណាស់ ព្រោះខ្ញុំត្រូវសង្ខេបបទពិសោធន៍ជាច្រើនឆ្នាំរបស់ខ្ញុំក្នុងរយៈពេល XNUMX នាទី។

នៅទីបញ្ចប់ខ្ញុំបានផ្តល់ឱ្យដូចខាងក្រោម និយមន័យនៃ DevOps៖ វាគឺជាសំណុំនៃការអនុវត្ត និងគំរូដែលអាចឱ្យការបំប្លែងធនធានមនុស្សទៅជាដើមទុនរបស់អង្គការដែលមានប្រសិទ្ធភាពខ្ពស់។ ឧទាហរណ៍​មួយ​គឺ​ជា​វិធី​ដែល​តូយ៉ូតា​បាន​ដំណើរការ​ក្នុង​រយៈ​ពេល 50 ឬ 60 ឆ្នាំ​ចុង​ក្រោយ​នេះ។

(តទៅនេះ ដ្យាក្រាមបែបនេះមិនត្រូវបានផ្តល់ជាឯកសារយោងទេ ប៉ុន្តែជាឧទាហរណ៍។ ខ្លឹមសាររបស់ពួកគេនឹងខុសគ្នាសម្រាប់ក្រុមហ៊ុនថ្មីនីមួយៗ។ ទោះជាយ៉ាងណាក៏ដោយ រូបភាពអាចត្រូវបានមើលដោយឡែកពីគ្នា និងពង្រីក។ នៅតំណនេះ។)

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

ខ្ញុំគិតថាកំហុសដែលសហសេវិករបស់ខ្ញុំជាច្រើនបានធ្វើគឺថាពួកគេគ្រាន់តែផ្តល់ឱ្យក្រុមហ៊ុននូវការណែនាំប្រាំចំណុចហើយបន្ទាប់មកត្រលប់មកវិញប្រាំមួយខែក្រោយមកហើយមើលអ្វីដែលបានកើតឡើង។ សូម្បីតែគ្រោងការណ៍ដ៏ល្អមួយ ដូចជាការគូសផែនទីស្ទ្រីមតម្លៃ មានចំណុចពិការភ្នែក។ បន្ទាប់ពីសំភាសន៍រាប់រយជាមួយនាយកក្រុមហ៊ុនផ្សេងៗ ខ្ញុំបានបង្កើតគំរូជាក់លាក់មួយដែលអនុញ្ញាតឱ្យយើងបំបែកបញ្ហាទៅជាសមាសធាតុរបស់វា ហើយឥឡូវនេះយើងនឹងពិភាក្សាគ្នាអំពីធាតុផ្សំទាំងនេះតាមលំដាប់លំដោយ។ មុនពេលអនុវត្តដំណោះស្រាយបច្ចេកវិជ្ជាណាមួយខ្ញុំប្រើលំនាំនេះហើយជាលទ្ធផលជញ្ជាំងទាំងអស់របស់ខ្ញុំត្រូវបានគ្របដណ្ដប់ដោយដ្យាក្រាម។ ថ្មីៗនេះខ្ញុំកំពុងធ្វើការជាមួយមូលនិធិទៅវិញទៅមក ហើយខ្ញុំបានបញ្ចប់ជាមួយនឹង 100-150 គ្រោងការណ៍បែបនេះ។

វប្បធម៌មិនល្អ បរិភោគវិធីសាស្រ្តល្អសម្រាប់អាហារពេលព្រឹក

គំនិតសំខាន់គឺនេះ៖ គ្មានចំនួន Lean, Agile, SAFE និង DevOps នឹងជួយទេ ប្រសិនបើវប្បធម៌របស់អង្គការខ្លួនឯងមិនល្អ។ វាដូចជាការមុជទឹកទៅជម្រៅដោយគ្មានឧបករណ៍ស្កាយបា ឬដំណើរការដោយគ្មានកាំរស្មីអ៊ិច។ ម៉្យាងទៀត ដើម្បីបកស្រាយអំពី Drucker និង Deming៖ វប្បធម៌រៀបចំមិនល្អនឹងលេបយកប្រព័ន្ធល្អណាមួយដោយមិនជាប់គាំង។

ដើម្បីដោះស្រាយបញ្ហាចម្បងនេះ អ្នកត្រូវចាត់វិធានការដូចខាងក្រោមៈ

1. ធ្វើឱ្យការងារទាំងអស់មើលឃើញ៖ អ្នកត្រូវធ្វើឱ្យការងារទាំងអស់មើលឃើញ។ មិន​មែន​ក្នុង​ន័យ​ថា​វា​ត្រូវ​តែ​បង្ហាញ​នៅ​លើ​អេក្រង់​មួយ​ចំនួន​នោះ​ទេ ប៉ុន្តែ​ក្នុង​ន័យ​ថា​វា​ត្រូវ​តែ​អាច​សង្កេត​បាន។
2. ប្រព័ន្ធគ្រប់គ្រងការងាររួម៖ ប្រព័ន្ធគ្រប់គ្រងត្រូវតែរួមបញ្ចូលគ្នា។ នៅក្នុងបញ្ហានៃចំណេះដឹង "កុលសម្ព័ន្ធ" និងចំណេះដឹងស្ថាប័ន, ក្នុង 9 ករណីក្នុងចំណោម 10 បញ្ហាគឺមនុស្ស។ នៅក្នុងសៀវភៅ "គម្រោង Phoenix" បញ្ហាគឺជាមួយមនុស្សតែម្នាក់គឺ Brent ដែលបណ្តាលឱ្យគម្រោងនេះមានរយៈពេលបីឆ្នាំក្រោយកាលវិភាគ។ ហើយខ្ញុំរត់ចូលទៅក្នុង "Brents" ទាំងនេះគ្រប់ទីកន្លែង។ ដើម្បីដោះស្រាយការស្ទះទាំងនេះ ខ្ញុំប្រើធាតុពីរបន្ទាប់នៅក្នុងបញ្ជីរបស់យើង។
3. ទ្រឹស្ដី​នៃ​វិធី​សា​ស្រ្ត​នៃ​ការ​រឹត​បន្តឹង​: ទ្រឹស្តីនៃឧបសគ្គ។
4. ការលួចចូលសហការ៖ ការ hack កិច្ចសហប្រតិបត្តិការ។
5. តូយ៉ូតា កាតា (ការបង្វឹកកាតា): ខ្ញុំនឹងមិននិយាយច្រើនអំពី Toyota Kata ទេ។ បើមានចំណាប់អារម្មណ៍ សូមចូលទៅកាន់ github របស់ខ្ញុំ មានបទបង្ហាញ ស្ទើរតែគ្រប់ប្រធានបទទាំងនេះ។
6. អង្គការតម្រង់ទិសទីផ្សារ៖ អង្គការតម្រង់ទិសទីផ្សារ។
7. សវនករប្តូរ-ឆ្វេង៖ សវនកម្មនៅដំណាក់កាលដំបូងនៃវដ្ត។

ខ្ញុំចាប់ផ្តើមធ្វើការជាមួយអង្គការមួយយ៉ាងសាមញ្ញ៖ ខ្ញុំទៅក្រុមហ៊ុន ហើយនិយាយជាមួយបុគ្គលិក។ ដូចដែលអ្នកអាចឃើញមិនមានបច្ចេកវិទ្យាខ្ពស់ទេ។ អ្វីដែលអ្នកត្រូវការគឺអ្វីដែលត្រូវសរសេរ។ ខ្ញុំប្រមូលផ្តុំក្រុមជាច្រើននៅក្នុងបន្ទប់មួយ ហើយវិភាគអ្វីដែលពួកគេប្រាប់ខ្ញុំតាមទស្សនៈនៃ 7 archetypes របស់ខ្ញុំ។ រួច​ខ្ញុំ​ដាក់​សញ្ញា​សម្គាល់​ឲ្យ​គេ​ដោយ​ខ្លួន​ឯង ហើយ​សុំ​ឲ្យ​គេ​សរសេរ​នៅ​លើ​ក្ដារខៀន​នូវ​អ្វី​គ្រប់​យ៉ាង​ដែល​គេ​បាន​និយាយ​ខ្លាំងៗ​មក​ទល់​ពេល​នេះ។ ជាធម្មតានៅក្នុងប្រភេទនៃការប្រជុំទាំងនេះមានមនុស្សម្នាក់ដែលសរសេរអ្វីៗគ្រប់យ៉ាង ហើយល្អបំផុតគាត់អាចសរសេរចុះបាន 10% នៃការពិភាក្សា។ ជាមួយនឹងវិធីសាស្រ្តរបស់ខ្ញុំ តួលេខនេះអាចកើនឡើងដល់ប្រហែល 40%។

(រូបភាពនេះអាចមើលដោយឡែកពីគ្នា។ សូមមើលតំណ)

វិធីសាស្រ្តរបស់ខ្ញុំគឺផ្អែកលើការងាររបស់ William Schneider ។ ជម្មើសជំនួស វិស្វកម្មឡើងវិញ) វិធីសាស្រ្តគឺផ្អែកលើគំនិតដែលថាអង្គការណាមួយអាចបែងចែកជាបួនការ៉េ។ គ្រោងការណ៍នេះសម្រាប់ខ្ញុំជាធម្មតាគឺជាលទ្ធផលនៃការធ្វើការជាមួយគ្រោងការណ៍រាប់រយផ្សេងទៀតដែលកើតឡើងនៅពេលវិភាគអង្គការមួយ។ ឧបមាថាយើងមានអង្គការមួយដែលមានកម្រិតខ្ពស់នៃការគ្រប់គ្រងប៉ុន្តែមានសមត្ថកិច្ចទាប។ នេះ​ជា​ជម្រើស​មិន​គួរ​ឱ្យ​ចង់​បាន​ខ្លាំង​ណាស់៖ នៅ​ពេល​ដែល​អ្នក​រាល់​គ្នា​ឈាន​ជើង​ដល់​ជួរ ប៉ុន្តែ​គ្មាន​នរណា​ដឹង​ថា​ត្រូវ​ធ្វើ​យ៉ាង​ណា​ទេ។

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

(រូបភាពនេះអាចមើលដោយឡែកពីគ្នា។ សូមមើលតំណ)

វាហាក់បីដូចជាខ្ញុំថា វិធីសាស្រ្តដែលមានគោលការណ៍ណែនាំតឹងរឹង បញ្ចប់ទៅជាផ្លូវនៃការសម្រេចបាននូវការពិត។ នៅក្នុងការគូសផែនទីស្ទ្រីមតម្លៃជាពិសេស មានច្បាប់ជាច្រើនទាក់ទងនឹងរបៀបដែលព័ត៌មានគួរតែត្រូវបានរៀបចំឡើង។ នៅក្នុងដំណាក់កាលដំបូងនៃការងារ ដែលខ្ញុំកំពុងនិយាយនៅពេលនេះ គ្មាននរណាម្នាក់ត្រូវការច្បាប់ទាំងនេះទេ។ ប្រសិនបើមនុស្សម្នាក់ដែលមានសញ្ញាសម្គាល់នៅក្នុងដៃរបស់គាត់ពិពណ៌នាអំពីស្ថានភាពជាក់ស្តែងនៅក្នុងក្រុមហ៊ុននៅលើក្តារនោះ នេះគឺជាវិធីល្អបំផុតដើម្បីយល់ពីស្ថានភាពនៃកិច្ចការ។ ព័ត៌មានបែបនេះមិនទៅដល់នាយកទេ។ នៅ​ពេល​នេះ វា​ជា​រឿង​ឆោតល្ងង់​ដែល​រំខាន​មនុស្ស​នោះ ហើយ​និយាយ​ថា​គាត់​គូស​ព្រួញ​ខុស​ខ្លះ។ នៅដំណាក់កាលនេះ វាជាការប្រសើរក្នុងការប្រើច្បាប់សាមញ្ញ ឧទាហរណ៍៖ អរូបីពហុកម្រិតអាចត្រូវបានបង្កើតយ៉ាងសាមញ្ញដោយប្រើសញ្ញាសម្គាល់ពហុពណ៌។

ខ្ញុំនិយាយម្តងទៀត គ្មានបច្ចេកវិទ្យាខ្ពស់ទេ។ សញ្ញាសម្គាល់ខ្មៅបង្ហាញពីការពិតគោលបំណងនៃរបៀបដែលអ្វីៗដំណើរការ។ ជាមួយនឹងសញ្ញាសម្គាល់ពណ៌ក្រហម មនុស្សសម្គាល់អ្វីដែលពួកគេមិនចូលចិត្តអំពីស្ថានភាពបច្ចុប្បន្ន។ សំខាន់ពួកគេសរសេរនេះ មិនមែនខ្ញុំទេ។ នៅពេលខ្ញុំទៅ CIO បន្ទាប់ពីកិច្ចប្រជុំ ខ្ញុំមិនផ្តល់បញ្ជី 10 ដែលត្រូវជួសជុលនោះទេ។ ខ្ញុំព្យាយាមស្វែងរកទំនាក់ទំនងរវាងអ្វីដែលមនុស្សនៅក្នុងក្រុមហ៊ុនកំពុងនិយាយ និងគំរូដែលបានបញ្ជាក់ដែលមានស្រាប់។ ជាចុងក្រោយ សញ្ញាសម្គាល់ពណ៌ខៀវបង្ហាញពីដំណោះស្រាយដែលអាចកើតមានចំពោះបញ្ហា។

(រូបភាពនេះអាចមើលដោយឡែកពីគ្នា។ សូមមើលតំណ)

ឧទាហរណ៍នៃវិធីសាស្រ្តនេះឥឡូវនេះត្រូវបានបង្ហាញខាងលើ។ នៅដើមឆ្នាំនេះខ្ញុំបានធ្វើការជាមួយធនាគារមួយ។ សន្តិសុខនៅទីនោះបានជឿជាក់ថា ពួកគេមិនគួរមកពិនិត្យការរចនា និងតម្រូវការនោះទេ។

(រូបភាពនេះអាចមើលដោយឡែកពីគ្នា។ សូមមើលតំណ)

ហើយបន្ទាប់មកយើងបាននិយាយជាមួយមនុស្សមកពីនាយកដ្ឋានផ្សេងទៀត ហើយវាបានប្រែក្លាយថាប្រហែល 8 ឆ្នាំមុនអ្នកបង្កើតកម្មវិធីបានបណ្តេញបុគ្គលិកសន្តិសុខដោយសារតែពួកគេធ្វើឱ្យការងារយឺតយ៉ាវ។ ហើយបន្ទាប់មកវាបានប្រែក្លាយទៅជាការហាមប្រាម ដែលត្រូវបានទទួលយក។ ទោះបីជាការពិតមិនមានការហាមឃាត់ក៏ដោយ។

ការប្រជុំរបស់យើងបានដំណើរការដោយភាពច្របូកច្របល់យ៉ាងខ្លាំង៖ អស់រយៈពេលប្រហែលបីម៉ោង ក្រុមប្រាំផ្សេងគ្នាមិនអាចពន្យល់ខ្ញុំពីអ្វីដែលកំពុងកើតឡើងរវាងកូដ និងការជួបប្រជុំគ្នានោះទេ។ ហើយនេះហាក់ដូចជារឿងសាមញ្ញបំផុត។ អ្នកប្រឹក្សា DevOps ភាគច្រើនសន្មត់ជាមុនថា អ្នករាល់គ្នាដឹងរឿងនេះរួចហើយ។

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

(រូបភាពនេះអាចមើលដោយឡែកពីគ្នា។ សូមមើលតំណ)

កិច្ចប្រជុំចុងក្រោយនៅធនាគារនេះគឺជាមួយនឹងក្រុមកម្មវិធីវិនិយោគ។ វាគឺនៅជាមួយនាងដែលវាបានប្រែក្លាយថាការសរសេរដ្យាក្រាមដែលមានសញ្ញាសម្គាល់នៅលើសន្លឹកក្រដាសគឺប្រសើរជាងនៅលើក្តារបន្ទះ ហើយថែមទាំងល្អជាងនៅលើបន្ទះឆ្លាតវៃទៀតផង។

រូបថតដែលអ្នកឃើញគឺជាអ្វីដែលបន្ទប់សន្និសិទសណ្ឋាគារមើលទៅដូចនៅថ្ងៃទីបួននៃការប្រជុំរបស់យើង។ ហើយយើងបានប្រើគ្រោងការណ៍ទាំងនេះដើម្បីស្វែងរកលំនាំ ពោលគឺ archetype

ដូច្នេះ ខ្ញុំ​សួរ​សំណួរ​កម្មករ ពួកគេ​សរសេរ​ចម្លើយ​ដោយ​មាន​សញ្ញា​សម្គាល់​បី​ពណ៌ (ខ្មៅ ក្រហម និង​ខៀវ)។ ខ្ញុំវិភាគចម្លើយរបស់ពួកគេសម្រាប់ archetypes ។ ឥឡូវនេះសូមពិភាក្សាអំពី archetypes ទាំងអស់តាមលំដាប់លំដោយ។

1. ធ្វើឱ្យការងារទាំងអស់អាចមើលឃើញ: ធ្វើឱ្យការងារមើលឃើញ

ក្រុមហ៊ុនភាគច្រើនដែលខ្ញុំធ្វើការជាមួយមានភាគរយខ្ពស់នៃការងារដែលមិនស្គាល់។ ឧទាហរណ៍ នេះ​ជា​ពេល​ដែល​បុគ្គលិក​ម្នាក់​មក​រក​ម្នាក់​ទៀត ហើយ​គ្រាន់​តែ​សុំ​ធ្វើ​អ្វី​មួយ។ នៅក្នុងអង្គការធំ ៗ អាចមានការងារដែលមិនបានគ្រោងទុក 60% ។ ហើយរហូតដល់ 40% នៃការងារមិនត្រូវបានចងក្រងជាឯកសារតាមមធ្យោបាយណាមួយឡើយ។ ប្រសិនបើវាជាក្រុមហ៊ុន Boeing ខ្ញុំនឹងមិនឡើងយន្តហោះរបស់ពួកគេទៀតទេក្នុងជីវិតរបស់ខ្ញុំ។ ប្រសិនបើមានតែពាក់កណ្តាលនៃការងារត្រូវបានចងក្រងជាឯកសារនោះ គេមិនដឹងថា តើការងារនេះត្រូវបានធ្វើត្រឹមត្រូវឬអត់នោះទេ។ វិធីសាស្រ្តផ្សេងទៀតទាំងអស់ប្រែទៅជាគ្មានប្រយោជន៍ - វាគ្មានចំណុចណាក្នុងការព្យាយាមស្វ័យប្រវត្តិកម្មអ្វីនោះទេព្រោះ 50% ដែលគេស្គាល់អាចជាផ្នែកដែលស៊ីសង្វាក់គ្នា និងច្បាស់លាស់បំផុតនៃការងារ ស្វ័យប្រវត្តិកម្មដែលនឹងមិនផ្តល់លទ្ធផលដ៏អស្ចារ្យ និងអាក្រក់បំផុតទាំងអស់។ អ្វីៗស្ថិតនៅក្នុងពាក់កណ្តាលដែលមើលមិនឃើញ។ អវត្ដមាននៃឯកសារ វាមិនអាចទៅរួចទេក្នុងការស្វែងរកគ្រប់ប្រភេទនៃការលួចចូល និងការងារដែលលាក់កំបាំង មិនមែនដើម្បីស្វែងរកការរាំងស្ទះនោះទេ "Brents" ដែលខ្ញុំបាននិយាយរួចហើយ។ មានសៀវភៅដ៏អស្ចារ្យមួយដោយ Dominica DeGrandis "ធ្វើឱ្យការងារមើលឃើញ". នាងបង្ហាញ "ការលេចធ្លាយពេលវេលា" ប្រាំផ្សេងគ្នា (ចោរពេលវេលា)៖

• ការងារច្រើនពេកនៅក្នុងដំណើរការ (WIP)
• ភាពអាស្រ័យមិនស្គាល់
• ការងារដែលមិនបានគ្រោងទុក
• អាទិភាពជម្លោះ
• ការងារដែលមិនយកចិត្តទុកដាក់

នេះគឺជាការវិភាគដ៏មានតម្លៃណាស់ ហើយសៀវភៅនេះគឺអស្ចារ្យណាស់ ប៉ុន្តែដំបូន្មានទាំងអស់នេះគ្មានប្រយោជន៍ទេ ប្រសិនបើមានតែ 50% នៃទិន្នន័យប៉ុណ្ណោះដែលអាចមើលឃើញ។ វិធីសាស្រ្តដែលស្នើឡើងដោយ Dominica អាចត្រូវបានប្រើប្រសិនបើភាពត្រឹមត្រូវលើសពី 90% ត្រូវបានសម្រេច។ ខ្ញុំកំពុងនិយាយអំពីស្ថានភាពដែលចៅហ្វាយផ្តល់ឱ្យអ្នកក្រោមបង្គាប់នូវកិច្ចការ 15 នាទី ប៉ុន្តែត្រូវចំណាយពេលបីថ្ងៃ។ ប៉ុន្តែចៅហ្វាយពិតជាមិនដឹងថាអ្នកក្រោមបង្គាប់នេះពឹងផ្អែកលើមនុស្សបួនឬប្រាំនាក់ផ្សេងទៀត។

គម្រោង Phoenix គឺជារឿងដ៏អស្ចារ្យមួយអំពីគម្រោងដែលហួសពេលបីឆ្នាំ។ តួអង្គមួយប្រឈមមុខនឹងការបណ្តេញចេញដោយសារតែរឿងនេះ ហើយគាត់បានជួបជាមួយនឹងតួអង្គផ្សេងទៀតដែលត្រូវបានបង្ហាញជាប្រភេទសូក្រាត។ គាត់ជួយរកឱ្យឃើញនូវអ្វីដែលពិតជាខុស។ វាប្រែថាក្រុមហ៊ុនមានអ្នកគ្រប់គ្រងប្រព័ន្ធមួយឈ្មោះ Brent ហើយការងារទាំងអស់ឆ្លងកាត់គាត់។ នៅក្នុងកិច្ចប្រជុំមួយ មន្ត្រីក្រោមឱវាទម្នាក់ត្រូវបានសួរថាៈ ហេតុអ្វីបានជាកិច្ចការកន្លះម៉ោងនីមួយៗត្រូវចំណាយពេលមួយសប្តាហ៍? ចម្លើយគឺជាបទបង្ហាញដ៏សាមញ្ញបំផុតនៃទ្រឹស្ដីតម្រង់ជួរ និងច្បាប់របស់ Little ហើយនៅក្នុងបទបង្ហាញនេះ វាបង្ហាញថានៅ 90% កាន់កាប់ម៉ោងធ្វើការនីមួយៗត្រូវចំណាយពេល 9 ម៉ោង។ កិច្ចការនីមួយៗត្រូវផ្ញើទៅមនុស្សប្រាំពីរនាក់ទៀត ដូច្នេះម៉ោងនោះក្លាយជា 63 ម៉ោង 7 ដង 9. ចំណុចដែលខ្ញុំកំពុងធ្វើគឺថា ដើម្បីប្រើច្បាប់របស់ Little ឬទ្រឹស្ដីតម្រង់ជួរដ៏ស្មុគស្មាញណាមួយ យ៉ាងហោចណាស់អ្នកត្រូវមានទិន្នន័យ។

ដូច្នេះនៅពេលខ្ញុំនិយាយអំពីភាពមើលឃើញ ខ្ញុំមិនមានន័យថាអ្វីគ្រប់យ៉ាងគឺនៅលើអេក្រង់នោះទេ ប៉ុន្តែយ៉ាងហោចណាស់អ្នកមានទិន្នន័យ។ នៅពេលដែលពួកគេធ្វើ វាច្រើនតែបង្ហាញថាមានការងារដែលមិនបានគ្រោងទុកយ៉ាងច្រើន ដែលត្រូវបានបញ្ជូនទៅ Brent នៅពេលដែលមិនត្រូវការវា។ ហើយ Brent គឺជាបុរសដ៏អស្ចារ្យ គាត់នឹងមិនដែលនិយាយថាទេ ប៉ុន្តែគាត់មិនប្រាប់នរណាម្នាក់ពីរបៀបដែលគាត់ធ្វើការងាររបស់គាត់។

នៅពេលដែលការងារអាចមើលឃើញ ទិន្នន័យអាចត្រូវបានចាត់ថ្នាក់យ៉ាងស្អាត (នោះជាអ្វីដែល Dominika កំពុងធ្វើនៅក្នុងរូបថត) ការអរូបីនៃការលេចធ្លាយប្រាំដងអាចត្រូវបានអនុវត្ត ហើយស្វ័យប្រវត្តិកម្មអាចត្រូវបានអនុវត្ត។

2. បង្រួបបង្រួមប្រព័ន្ធគ្រប់គ្រងការងារ៖ ការគ្រប់គ្រងកិច្ចការ

archetypes ដែលខ្ញុំកំពុងនិយាយអំពី គឺជាប្រភេទពីរ៉ាមីត។ ប្រសិនបើទីមួយត្រូវបានធ្វើបានត្រឹមត្រូវ នោះទីពីរគឺជាប្រភេទនៃកម្មវិធីបន្ថែមរួចហើយ។ ភាគច្រើននៃទាំងនេះមិនដំណើរការសម្រាប់ការចាប់ផ្តើមអាជីវកម្មនោះទេ ពួកគេត្រូវរក្សាទុកក្នុងចិត្តសម្រាប់ក្រុមហ៊ុនធំៗដូចជា Fortune 5000។ ក្រុមហ៊ុនចុងក្រោយដែលខ្ញុំធ្វើការឱ្យ មានប្រព័ន្ធលក់សំបុត្រចំនួន 10 ។ ក្រុមមួយមាន Remedy មួយក្រុមទៀតសរសេរប្រព័ន្ធផ្ទាល់ខ្លួនខ្លះ ទីបីប្រើ Jira និងខ្លះទៀតបង្កើតជាមួយអ៊ីមែល។ បញ្ហាដូចគ្នានេះកើតឡើងប្រសិនបើក្រុមហ៊ុនមានបំពង់ចំនួន 30 ផ្សេងគ្នា ប៉ុន្តែខ្ញុំមិនមានពេលវេលាដើម្បីពិភាក្សាអំពីករណីបែបនេះទាំងអស់នោះទេ។

ខ្ញុំពិភាក្សាជាមួយមនុស្សឱ្យច្បាស់អំពីរបៀបដែលសំបុត្រត្រូវបានបង្កើតឡើង តើមានអ្វីកើតឡើងចំពោះពួកគេបន្ទាប់ និងរបៀបដែលពួកគេត្រូវបានជៀសវាង។ អ្វី​ដែល​គួរ​ឱ្យ​ចាប់​អារម្មណ៍​បំផុត​នោះ​គឺ​ថា មនុស្ស​ក្នុង​ការ​ប្រជុំ​របស់​យើង​និយាយ​ដោយ​ស្មោះ​ត្រង់។ ខ្ញុំបានសួរថាតើមានមនុស្សប៉ុន្មាននាក់ដែលដាក់ "ផលប៉ះពាល់តិចតួច / គ្មានផលប៉ះពាល់" លើសំបុត្រដែលគួរត្រូវបានផ្តល់ "ផលប៉ះពាល់ធំ" ។ វាប្រែថាស្ទើរតែគ្រប់គ្នាធ្វើបែបនេះ។ ខ្ញុំ​មិន​ចូល​រួម​ក្នុង​ការ​បរិហារ​ទេ ហើយ​ព្យាយាម​គ្រប់​វិធី​ដែល​អាច​ធ្វើ​ទៅ​បាន​ដើម្បី​មិន​កំណត់​អត្តសញ្ញាណ​មនុស្ស។ ពេល​គេ​សារភាព​ដោយ​ស្មោះ​អស់​ពី​ចិត្ត​ចំពោះ​ខ្ញុំ ខ្ញុំ​មិន​ឲ្យ​គេ​ទៅ​ណា​ទេ។ ប៉ុន្តែនៅពេលដែលមនុស្សស្ទើរតែទាំងអស់ឆ្លងកាត់ប្រព័ន្ធ វាមានន័យថាសុវត្ថិភាពទាំងអស់គឺជាការស្លៀកពាក់បង្អួច។ ដូច្នេះហើយ គ្មានការសន្និដ្ឋានណាមួយអាចត្រូវបានទាញចេញពីទិន្នន័យនៃប្រព័ន្ធនេះទេ។

ដើម្បីដោះស្រាយបញ្ហាសំបុត្រអ្នកត្រូវជ្រើសរើសប្រព័ន្ធសំខាន់មួយ។ ប្រសិនបើអ្នកប្រើ Jira ទុក Jira ។ បើ​មាន​ជម្រើស​ណា​មួយ សូម​ឲ្យ​វា​មាន​តែ​មួយ។ ចំណុចសំខាន់គឺថាសំបុត្រគួរតែត្រូវបានមើលថាជាជំហានមួយផ្សេងទៀតនៅក្នុងដំណើរការអភិវឌ្ឍន៍។ រាល់សកម្មភាពត្រូវតែមានសំបុត្រ ដែលត្រូវតែហូរកាត់លំហូរការងារអភិវឌ្ឍន៍។ សំបុត្រត្រូវបានផ្ញើទៅក្រុមដែលបង្ហោះវានៅលើផ្ទាំងរឿង ហើយបន្ទាប់មកទទួលខុសត្រូវចំពោះពួកគេ។

នេះអនុវត្តចំពោះនាយកដ្ឋានទាំងអស់ រួមទាំងហេដ្ឋារចនាសម្ព័ន្ធ និងប្រតិបត្តិការ។ ក្នុងករណីនេះ វាអាចបង្កើតបានយ៉ាងហោចណាស់នូវគំនិតដែលអាចជឿជាក់បាននៃស្ថានភាពកិច្ចការ។ នៅពេលដែលដំណើរការនេះត្រូវបានបង្កើតឡើង ភ្លាមៗនោះវានឹងងាយស្រួលក្នុងការកំណត់ថាអ្នកណាជាអ្នកទទួលខុសត្រូវចំពោះកម្មវិធីនីមួយៗ។ ព្រោះ​ឥឡូវ​នេះ​យើង​មិន​ទទួល​បាន 50% ប៉ុន្តែ 98% នៃ​សេវា​ថ្មី​។ ប្រសិនបើដំណើរការស្នូលនេះដំណើរការ នោះភាពត្រឹមត្រូវនឹងប្រសើរឡើងពេញប្រព័ន្ធ។

បំពង់សេវាកម្ម

នេះអនុវត្តម្តងទៀតចំពោះសាជីវកម្មធំៗប៉ុណ្ណោះ។ ប្រសិនបើអ្នកជាក្រុមហ៊ុនថ្មីនៅក្នុងវិស័យថ្មីមួយ សូមក្រឡុកដៃអាវរបស់អ្នក ហើយធ្វើការជាមួយ Travis CI ឬ CircleCI របស់អ្នក។ នៅពេលនិយាយអំពីក្រុមហ៊ុន Fortune 5000 ករណីមួយបានកើតឡើងនៅធនាគារដែលខ្ញុំធ្វើការ។ Google បានមករកពួកគេ ហើយពួកគេត្រូវបានបង្ហាញដ្យាក្រាមនៃប្រព័ន្ធ IBM ចាស់។ បុរសមកពី Google សួរដោយច្របូកច្របល់ - តើកូដប្រភពសម្រាប់រឿងនេះនៅឯណា? ប៉ុន្តែមិនមានកូដប្រភព សូម្បីតែ GUI ក៏ដោយ។ នេះគឺជាការពិតដែលអង្គការធំៗត្រូវដោះស្រាយ៖ កំណត់ត្រាធនាគារដែលមានអាយុ 40 ឆ្នាំនៅលើ mainframe បុរាណមួយ។ អតិថិជនរបស់ខ្ញុំម្នាក់ប្រើកុងតឺន័រ Kubernetes ជាមួយនឹងគំរូ Circuit Breaker បូករួមទាំង Chaos Monkey ទាំងអស់សម្រាប់កម្មវិធី KeyBank ។ ប៉ុន្តែធុងទាំងនេះនៅទីបំផុតភ្ជាប់ទៅកម្មវិធី COBOL ។

បុរសមកពី Google មានទំនុកចិត្តទាំងស្រុងថាពួកគេនឹងដោះស្រាយបញ្ហាទាំងអស់របស់អតិថិជនរបស់ខ្ញុំ ហើយបន្ទាប់មកពួកគេបានចាប់ផ្តើមសួរសំណួរ៖ តើ IBM datapipe គឺជាអ្វី? ពួកគេត្រូវបានគេប្រាប់: នេះគឺជាឧបករណ៍ភ្ជាប់។ តើវាភ្ជាប់ទៅអ្វី? ទៅប្រព័ន្ធ Sperry ។ ហើយនោះជាអ្វី? ល​ល។ មើលដំបូងវាហាក់ដូចជា: តើ DevOps អាចមានប្រភេទអ្វី? ប៉ុន្តែការពិតវាអាចទៅរួច។ មានប្រព័ន្ធចែកចាយដែលអនុញ្ញាតឱ្យអ្នកប្រគល់លំហូរការងារទៅឱ្យក្រុមដឹកជញ្ជូន។

3. Theory of Constraints : Theory of Constraints

ចូរបន្តទៅ archetype ទីបី: ចំណេះដឹងស្ថាប័ន / "កុលសម្ព័ន្ធ" ។ តាមក្បួនមួយនៅក្នុងអង្គការណាមួយមានមនុស្សជាច្រើនដែលដឹងអ្វីៗគ្រប់យ៉ាងនិងគ្រប់គ្រងអ្វីៗទាំងអស់។ ទាំងនេះគឺជាអ្នកដែលបាននៅក្នុងអង្គការយូរជាងគេហើយដែលដឹងពីវិធីដោះស្រាយទាំងអស់។

នៅពេលដែលវាកើតឡើងនៅលើដ្យាក្រាម ខ្ញុំជាពិសេសគូសរង្វង់មនុស្សបែបនេះជាមួយនឹងសញ្ញាសម្គាល់៖ ឧទាហរណ៍ វាបង្ហាញថា Lou ជាក់លាក់មួយមានវត្តមាននៅក្នុងកិច្ចប្រជុំទាំងអស់។ ហើយវាច្បាស់ណាស់សម្រាប់ខ្ញុំ៖ នេះគឺជា Brent ក្នុងស្រុក។ នៅពេលដែល CIO ជ្រើសរើសរវាងខ្ញុំក្នុងអាវយឺត និងស្បែកជើងប៉ាតា និងបុរសមកពី IBM ក្នុងឈុតមួយ ខ្ញុំត្រូវបានគេជ្រើសរើសព្រោះខ្ញុំអាចប្រាប់អ្នកដឹកនាំរឿងដែលបុរសម្នាក់ផ្សេងទៀតនឹងមិនប្រាប់ ហើយនាយកប្រហែលជាមិនចូលចិត្តស្តាប់។ . ខ្ញុំប្រាប់ពួកគេថា អ្នកដែលជាប់គាំងនៅក្នុងក្រុមហ៊ុនរបស់ពួកគេ គឺមនុស្សម្នាក់ឈ្មោះ Fred និងម្នាក់ឈ្មោះ Lou ។ ឧបសគ្គ​នេះ​ត្រូវ​ដោះ​ស្រាយ ចំណេះដឹង​របស់​ពួកគេ​ត្រូវ​ទទួល​បាន​ពី​ពួកគេ​តាម​មធ្យោបាយ​មួយ​ឬ​មធ្យោបាយ​ផ្សេង។

ដើម្បីដោះស្រាយបញ្ហាប្រភេទនេះ ខ្ញុំអាចឧទាហរណ៍ស្នើឱ្យប្រើ Slack ។ នាយកឆ្លាតនឹងសួរ - ហេតុអ្វី? ជាធម្មតា ក្នុងករណីបែបនេះ អ្នកប្រឹក្សា DevOps ឆ្លើយថា ពីព្រោះគ្រប់គ្នាកំពុងធ្វើវា។ បើអ្នកដឹកនាំពិតជាឆ្លាតមែន គាត់នឹងនិយាយថា៖ អញ្ចឹងម៉េច។ ហើយនេះគឺជាកន្លែងដែលការសន្ទនាបញ្ចប់។ ហើយចម្លើយរបស់ខ្ញុំចំពោះនេះគឺ៖ ដោយសារតែក្រុមហ៊ុនមានឧបសគ្គចំនួនបួនគឺ Fred, Lou, Susie និង Jane ។ ដើម្បីរៀបចំចំណេះដឹងរបស់ពួកគេជាលក្ខណៈស្ថាប័ន ដំបូងគេត្រូវតែណែនាំ Slack ។ វិគីទាំងអស់របស់អ្នកគឺសមហេតុសមផលទាំងស្រុង ពីព្រោះគ្មាននរណាម្នាក់ដឹងពីអត្ថិភាពរបស់វាទេ។ ប្រសិនបើក្រុមវិស្វករចូលរួមនៅក្នុងការអភិវឌ្ឍន៍ផ្នែកខាងមុខ និងផ្នែកខាងក្រោយ ហើយអ្នកគ្រប់គ្នាត្រូវដឹងថាពួកគេអាចទាក់ទងក្រុមអភិវឌ្ឍន៍ផ្នែកខាងមុខ ឬក្រុមហេដ្ឋារចនាសម្ព័ន្ធដោយមានសំណួរ។ នោះហើយជាពេលដែល Lou ឬ Fred ប្រហែលជាមានពេលដើម្បីចូលរួមវីគី។ ហើយបន្ទាប់មកនៅក្នុង Slack នរណាម្នាក់អាចសួរថាហេតុអ្វីបានជា និយាយថា ជំហានទី 5 មិនដំណើរការ។ ហើយបន្ទាប់មក Lou ឬ Fred នឹងកែតម្រូវការណែនាំនៅលើវីគី។ ប្រសិនបើអ្នកបង្កើតដំណើរការនេះ នោះអ្វីៗជាច្រើននឹងធ្លាក់មកដោយខ្លួនឯង។

នេះជាចំណុចសំខាន់របស់ខ្ញុំ៖ ដើម្បីណែនាំបច្ចេកវិទ្យាខ្ពស់ណាមួយ អ្នកត្រូវតែដាក់គ្រឹះសម្រាប់ពួកវាជាមុនសិន ហើយនេះអាចត្រូវបានធ្វើជាមួយនឹងដំណោះស្រាយបច្ចេកវិទ្យាទាបដែលទើបតែបានពិពណ៌នា។ ប្រសិនបើអ្នកចាប់ផ្តើមជាមួយបច្ចេកវិទ្យាខ្ពស់ហើយមិនពន្យល់ពីមូលហេតុដែលពួកគេត្រូវការនោះ តាមក្បួនវាមិនបញ្ចប់ល្អទេ។ អតិថិជនរបស់យើងម្នាក់ប្រើ Azure ML ដែលជាដំណោះស្រាយថោក និងសាមញ្ញបំផុត។ ប្រហែល 30% នៃសំណួររបស់ពួកគេត្រូវបានឆ្លើយដោយម៉ាស៊ីនរៀនដោយខ្លួនឯងផ្ទាល់។ ហើយរឿងនេះត្រូវបានសរសេរដោយប្រតិបត្តិករដែលមិនពាក់ព័ន្ធនឹងវិទ្យាសាស្ត្រទិន្នន័យ ស្ថិតិ ឬគណិតវិទ្យា។ នេះគឺសំខាន់។ តម្លៃនៃដំណោះស្រាយបែបនេះគឺតិចតួចបំផុត។

4. ការ hacks ការសហការ: ការ hacks កិច្ចសហប្រតិបត្តិការ

ប្រភេទទីបួនគឺជាតម្រូវការដើម្បីប្រយុទ្ធប្រឆាំងនឹងភាពឯកោ។ មនុស្សភាគច្រើនដឹងរឿងនេះរួចហើយ៖ ភាពឯកោបង្កើតអរិភាព។ ប្រសិនបើនាយកដ្ឋាននីមួយៗនៅជាន់ផ្ទាល់ដី ហើយមនុស្សមិនប្រសព្វគ្នាតាមមធ្យោបាយណាមួយឡើយ លើកលែងតែនៅក្នុងជណ្តើរយន្ត នោះអរិភាពរវាងពួកគេកើតឡើងយ៉ាងងាយ។ ប៉ុន្តែ​បើ​ផ្ទុយ​ទៅ​វិញ​មនុស្ស​នៅ​បន្ទប់​ជាមួយ​គ្នា នាង​ក៏​ចាកចេញ​ទៅ​ភ្លាម។ ជាឧទាហរណ៍ នៅពេលដែលនរណាម្នាក់បោះចោលការចោទប្រកាន់ទូទៅមួយចំនួន ជាឧទាហរណ៍ ចំណុចប្រទាក់បែបនេះ និងមិនដែលដំណើរការ គ្មានអ្វីងាយស្រួលជាងក្នុងការរំលាយការចោទប្រកាន់នោះទេ។ អ្នកសរសេរកម្មវិធីដែលសរសេរចំណុចប្រទាក់គ្រាន់តែត្រូវចាប់ផ្តើមសួរសំណួរជាក់លាក់ ហើយវានឹងច្បាស់ភ្លាមៗថា ជាឧទាហរណ៍ អ្នកប្រើប្រាស់គ្រាន់តែប្រើឧបករណ៍មិនត្រឹមត្រូវ។

មានវិធីជាច្រើនដើម្បីយកឈ្នះភាពឯកោ។ ខ្ញុំ​ធ្លាប់​ត្រូវ​គេ​សុំ​ទៅ​ប្រឹក្សា​ធនាគារ​នៅ​អូស្ត្រាលី ប៉ុន្តែ​ខ្ញុំ​មិន​ព្រម​ទេ ព្រោះ​ខ្ញុំ​មាន​កូន​ពីរ​នាក់ និង​ប្រពន្ធ។ អ្វីដែលខ្ញុំអាចធ្វើបានដើម្បីជួយពួកគេគឺណែនាំការនិទានរឿងបែបក្រាហ្វិក។ នេះ​ជា​អ្វី​ដែល​ត្រូវ​បាន​បញ្ជាក់​ថា​មាន​ប្រសិទ្ធភាព។ វិធីគួរឱ្យចាប់អារម្មណ៍មួយទៀតគឺការប្រជុំកាហ្វេគ្មានខ្លាញ់។ នៅក្នុងអង្គការធំមួយ នេះគឺជាជម្រើសដ៏ល្អសម្រាប់ការផ្សព្វផ្សាយចំណេះដឹង។ លើសពីនេះទៀតអ្នកអាចធ្វើ devopsdays ខាងក្នុង, hackathons និងដូច្នេះនៅលើ។

5. បង្វឹក Kata

ដូច​ដែល​ខ្ញុំ​បាន​ព្រមាន​នៅ​ដើម​ដំបូង ខ្ញុំ​នឹង​មិន​និយាយ​អំពី​រឿង​នេះ​នៅ​ថ្ងៃ​នេះ​ទេ។ បើចាប់អារម្មណ៍អាចចូលមើលបាន។ បទបង្ហាញខ្លះរបស់ខ្ញុំ.

ក៏មានសុន្ទរកថាដ៏ល្អលើប្រធានបទនេះពី Mike Rother៖

6. Market Oriented: អង្គការតម្រង់ទិសទីផ្សារ

មានបញ្ហាផ្សេងៗគ្នានៅទីនេះ។ ឧទាហរណ៍ "ខ្ញុំ" មនុស្ស "T" និង "E" ។ “ខ្ញុំ” គឺជាមនុស្សដែលធ្វើតែរឿងមួយ។ ជាធម្មតាពួកវាមាននៅក្នុងអង្គការដែលមាននាយកដ្ឋានដាច់ដោយឡែក។ “T” គឺជាពេលដែលមនុស្សពូកែលើរឿងមួយ ប៉ុន្តែក៏ពូកែលើរឿងផ្សេងទៀតដែរ។ "អ៊ី" ឬសូម្បីតែ "សិតសក់" គឺជាពេលដែលមនុស្សម្នាក់មានជំនាញជាច្រើន។

ច្បាប់ Conway ធ្វើការនៅទីនេះ (ច្បាប់របស់ Conway) ដែល​ក្នុង​ទម្រង់​សាមញ្ញ​បំផុត​អាច​បញ្ជាក់​បាន​ដូច​ខាង​ក្រោម៖ ប្រសិន​បើ​ក្រុម​បី​ធ្វើ​ការ​លើ​អ្នក​ចងក្រង នោះ​លទ្ធផល​នឹង​ក្លាយ​ជា​អ្នក​ចងក្រង​បី​ផ្នែក។ ដូច្នេះ ប្រសិនបើមានភាពឯកោកម្រិតខ្ពស់នៅក្នុងស្ថាប័នមួយ នោះសូម្បីតែ Kubernetes ឧបករណ៍បំប្លែងសៀគ្វី ការពង្រីក API និងវត្ថុប្លែកៗផ្សេងទៀតនៅក្នុងស្ថាប័ននេះ នឹងត្រូវបានរៀបចំតាមរបៀបដូចគ្នាទៅនឹងស្ថាប័នខ្លួនឯងដែរ។ យ៉ាងតឹងរ៉ឹងយោងទៅតាម Conway និងដើម្បីបញ្ឆោតអ្នក geeks វ័យក្មេងទាំងអស់។

ដំណោះស្រាយចំពោះបញ្ហានេះត្រូវបានពិពណ៌នាជាច្រើនដង។ ជាឧទាហរណ៍ មានគំរូនៃអង្គការដែលបានពិពណ៌នាដោយ Fernando Fernandez ។ ស្ថាបត្យកម្មដែលមានបញ្ហានោះ ដែលខ្ញុំទើបតែនិយាយអំពី ដោយភាពឯកោ គឺជាស្ថាបត្យកម្មតម្រង់ទិសមុខងារ។ ប្រភេទទីពីរគឺអាក្រក់បំផុត ស្ថាបត្យកម្មម៉ាទ្រីស រញ៉េរញ៉ៃនៃពីរផ្សេងទៀត។ ទីបីគឺជាអ្វីដែលត្រូវបានគេមើលឃើញនៅក្នុងការចាប់ផ្ដើមអាជីវកម្មភាគច្រើន ហើយក្រុមហ៊ុនធំៗក៏កំពុងព្យាយាមផ្គូផ្គងប្រភេទនេះផងដែរ។ វាគឺជាអង្គការដែលផ្តោតលើទីផ្សារ។ នៅទីនេះយើងបង្កើនប្រសិទ្ធភាពដើម្បីសម្រេចបាននូវការឆ្លើយតបលឿនបំផុតចំពោះសំណើរបស់អតិថិជន។ ជួនកាលគេហៅថាអង្គការផ្ទះល្វែង។

មនុស្ស​ជា​ច្រើន​ពណ៌នា​អំពី​រចនា​សម្ព័ន្ធ​នេះ​ក្នុង​លក្ខណៈ​ខុស​ៗ​គ្នា ខ្ញុំ​ចូល​ចិត្ត​ពាក្យ បង្កើត/ដំណើរការក្រុមនៅ Amazon ពួកគេហៅវា។ ក្រុមភីហ្សាពីរ. នៅក្នុងរចនាសម្ព័ន្ធនេះ មនុស្សប្រភេទ “I” ទាំងអស់ត្រូវបានដាក់ជាក្រុមជុំវិញសេវាកម្មមួយ ហើយបន្តិចម្តងៗពួកគេកាន់តែខិតទៅជិតប្រភេទ “T” ហើយប្រសិនបើការគ្រប់គ្រងត្រឹមត្រូវនោះ ពួកគេអាចក្លាយជា “E” ផងដែរ។ ការប្រឆាំងទីមួយនៅទីនេះគឺថារចនាសម្ព័ន្ធបែបនេះមានធាតុផ្សំដែលមិនចាំបាច់។ ហេតុអ្វីបានជាអ្នកត្រូវការអ្នកសាកល្បងនៅក្នុងនាយកដ្ឋាននីមួយៗ ប្រសិនបើអ្នកអាចមាននាយកដ្ឋានពិសេសរបស់អ្នកសាកល្បង? ដែលខ្ញុំឆ្លើយ៖ ការចំណាយបន្ថែមក្នុងករណីនេះគឺជាតម្លៃសម្រាប់អង្គភាពទាំងមូលដើម្បីក្លាយជាប្រភេទ "E" នាពេលអនាគត។ នៅក្នុងរចនាសម្ព័ន្ធនេះ អ្នកសាកល្បងរៀនបណ្តើរៗអំពីបណ្តាញ ស្ថាបត្យកម្ម ការរចនា។ល។ អាស្រ័យហេតុនេះ អ្នកចូលរួមគ្រប់រូបនៅក្នុងអង្គការគឺដឹងច្បាស់អំពីអ្វីគ្រប់យ៉ាងដែលកើតឡើងនៅក្នុងអង្គការ។ ប្រសិនបើអ្នកចង់ដឹងពីរបៀបដែលគ្រោងការណ៍នេះដំណើរការនៅក្នុងឧស្សាហកម្មសូមអាន Mike Rother, Toyota Kata.

7. សវនករប្តូរ-ឆ្វេង៖ សវនកម្មនៅដើមវដ្ត។ ការអនុលោមតាមច្បាប់សុវត្ថិភាពនៅលើការបង្ហាញ

នេះគឺជាពេលដែលសកម្មភាពរបស់អ្នកមិនឆ្លងកាត់ការធ្វើតេស្តក្លិន ដូច្នេះដើម្បីនិយាយ។ មនុស្សដែលធ្វើការឱ្យអ្នកមិនល្ងង់ទេ។ ប្រសិនបើដូចក្នុងឧទាហរណ៍ខាងលើ ពួកគេបានកំណត់ផលប៉ះពាល់តិចតួច ឬគ្មាននៅគ្រប់ទីកន្លែង វាមានរយៈពេលបីឆ្នាំ ហើយគ្មាននរណាម្នាក់កត់សម្គាល់អ្វីនោះទេ នោះអ្នកគ្រប់គ្នាដឹងយ៉ាងច្បាស់ថាប្រព័ន្ធមិនដំណើរការ។ ឬឧទាហរណ៍មួយទៀត - ក្រុមប្រឹក្សាផ្លាស់ប្តូរយោបល់ ដែលរបាយការណ៍ត្រូវដាក់ជូនរៀងរាល់ថ្ងៃពុធ។ មានក្រុមមនុស្សធ្វើការនៅទីនោះ (មិនសូវមានប្រាក់ខែច្រើនទេ) ដែលតាមទ្រឹស្តីគួរតែដឹងពីរបៀបដែលប្រព័ន្ធទាំងមូលដំណើរការ។ ហើយក្នុងរយៈពេលប្រាំឆ្នាំកន្លងមកនេះ អ្នកប្រហែលជាបានកត់សម្គាល់ឃើញថាប្រព័ន្ធរបស់យើងមានភាពស្មុគស្មាញមិនគួរឱ្យជឿ។ ហើយមនុស្ស 5 ឬ 6 នាក់ត្រូវធ្វើការសម្រេចចិត្តអំពីការផ្លាស់ប្តូរដែលពួកគេមិនបានធ្វើ និងអំពីអ្វីដែលពួកគេមិនដឹងអ្វីទាំងអស់។

ជាការពិតណាស់វិធីសាស្រ្តនេះមិនដំណើរការទេ។ ខ្ញុំ​ត្រូវ​តែ​កម្ចាត់​រឿង​បែប​នេះ​ចោល​ព្រោះ​មនុស្ស​ទាំង​នេះ​មិន​បាន​ការពារ​ប្រព័ន្ធ។ ការ​សម្រេច​ចិត្ត​ត្រូវ​តែ​ធ្វើ​ឡើង​ដោយ​ក្រុម​ខ្លួន​ឯង ព្រោះ​ក្រុម​ត្រូវ​តែ​ទទួល​ខុស​ត្រូវ។ បើមិនដូច្នេះទេ ស្ថានភាពផ្ទុយស្រឡះកើតឡើងនៅពេលដែលអ្នកគ្រប់គ្រងដែលមិនធ្លាប់សរសេរកូដក្នុងជីវិតរបស់គាត់ប្រាប់អ្នកសរសេរកម្មវិធីថាតើវាត្រូវចំណាយពេលប៉ុន្មានដើម្បីសរសេរកូដ។ ក្រុមហ៊ុនមួយដែលខ្ញុំបានធ្វើការជាមួយមានក្រុមប្រឹក្សាចំនួន 7 ផ្សេងគ្នាដែលពិនិត្យមើលរាល់ការផ្លាស់ប្តូរ រួមទាំងក្រុមប្រឹក្សាភិបាលស្ថាបត្យកម្ម ក្រុមប្រឹក្សាផលិតផល។ល។ មានសូម្បីតែរយៈពេលរង់ចាំជាកាតព្វកិច្ច ទោះបីជានិយោជិតម្នាក់បានប្រាប់ខ្ញុំថាក្នុងរយៈពេលដប់ឆ្នាំនៃការងារ គ្មាននរណាម្នាក់ធ្លាប់បដិសេធការផ្លាស់ប្តូរដែលធ្វើឡើងដោយបុគ្គលនេះក្នុងអំឡុងពេលចាំបាច់នោះទេ។

សវនករត្រូវតែត្រូវបានអញ្ជើញឱ្យចូលរួមជាមួយយើង ហើយមិនត្រូវកម្ចាត់ពួកគេចោលឡើយ។ ប្រាប់ពួកគេថាអ្នកសរសេរធុងគោលពីរដែលមិនអាចផ្លាស់ប្តូរបានថាប្រសិនបើពួកគេឆ្លងកាត់ការសាកល្បងទាំងអស់នោះ នៅតែមិនអាចផ្លាស់ប្តូរជារៀងរហូត។ ប្រាប់ពួកគេថាអ្នកមានបំពង់បង្ហូរជាកូដ ហើយពន្យល់ពីអត្ថន័យរបស់វា។ បង្ហាញពួកវានូវគ្រោងការណ៍ខាងក្រោម៖ ប្រព័ន្ធគោលពីរដែលអាចអានបានតែមិនអាចផ្លាស់ប្តូរបាននៅក្នុងកុងតឺន័រដែលឆ្លងកាត់ការធ្វើតេស្តភាពងាយរងគ្រោះទាំងអស់។ ហើយបន្ទាប់មកមិនត្រឹមតែគ្មាននរណាម្នាក់ប៉ះវាទេ ពួកគេមិនថែមទាំងប៉ះប្រព័ន្ធដែលបង្កើតបំពង់បង្ហូរប្រេងនោះទេ ព្រោះវាក៏ត្រូវបានបង្កើតយ៉ាងសកម្មផងដែរ។ ខ្ញុំមានអតិថិជន Capital One ដែលកំពុងប្រើ Vault ដើម្បីបង្កើតអ្វីមួយដូចជា blockchain ។ សវនករមិនចាំបាច់បង្ហាញ "រូបមន្ត" ពីមេចុងភៅទេវាគ្រប់គ្រាន់ដើម្បីបង្ហាញ blockchain ដែលវាច្បាស់ថាមានអ្វីកើតឡើងចំពោះសំបុត្រ Jira នៅក្នុងផលិតកម្មហើយអ្នកណាទទួលខុសត្រូវចំពោះវា។

នេះបើយោងតាម របាយការណ៍ដែលត្រូវបានបង្កើតឡើងក្នុងឆ្នាំ 2018 ដោយ Sonatype មានសំណើទាញយក OSS ចំនួន 2017 ពាន់លានក្នុងឆ្នាំ 87។

ការខាតបង់ដែលកើតឡើងដោយសារភាពងាយរងគ្រោះត្រូវបានហាមឃាត់។ ជាងនេះទៅទៀត តួលេខដែលអ្នកឃើញខាងលើមិនរាប់បញ្ចូលការចំណាយលើឱកាសនោះទេ។ តើ DevSecOps ជាអ្វី? ខ្ញុំ​សូម​និយាយ​ភ្លាម​ថា ខ្ញុំ​មិន​ចាប់​អារម្មណ៍​នឹង​និយាយ​ថា​តើ​ឈ្មោះ​នេះ​ជោគជ័យ​ប៉ុណ្ណា​ទេ។ ចំនុចនោះគឺថាចាប់តាំងពី DevOps បានទទួលជោគជ័យដូច្នេះយើងគួរតែព្យាយាមបន្ថែមសុវត្ថិភាពទៅបំពង់បង្ហូរនោះ។

ឧទាហរណ៍នៃលំដាប់នេះ៖


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

ហើយ​គ្មាន​ហេតុផល​អ្វី​ដែល​យើង​មិន​អាច​ប្រើ​វិធី​ដូចគ្នា​ចំពោះ​សុវត្ថិភាព​នោះ​ទេ។

លទ្ធផល

ជាការសន្និដ្ឋាន ខ្ញុំនឹងផ្តល់គន្លឹះខ្លះៗសម្រាប់ DevSecOps ។ អ្នកត្រូវបញ្ចូលសវនករក្នុងដំណើរការបង្កើតប្រព័ន្ធរបស់អ្នក ហើយចំណាយពេលអប់រំពួកគេ។ អ្នកត្រូវសហការជាមួយសវនករ។ បន្ទាប់មក អ្នកត្រូវធ្វើការប្រយុទ្ធដោយគ្មានមេត្តា ប្រឆាំងនឹងភាពវិជ្ជមានមិនពិត។ ទោះបីជាមានឧបករណ៍ស្កែនភាពងាយរងគ្រោះថ្លៃបំផុតក៏ដោយ អ្នកអាចបង្កើតទម្លាប់អាក្រក់បំផុតក្នុងចំណោមអ្នកអភិវឌ្ឍន៍របស់អ្នក ប្រសិនបើអ្នកមិនដឹងថាសមាមាត្រសញ្ញាទៅសំឡេងរបស់អ្នកគឺជាអ្វី។ អ្នក​អភិវឌ្ឍន៍​នឹង​មាន​ការ​ស្រើបស្រាល​នឹង​ព្រឹត្តិការណ៍ ហើយ​នឹង​លុប​វា​ចោល។ ប្រសិនបើអ្នកបានឮអំពីរឿង Equifax នោះជាអ្វីដែលបានកើតឡើងនៅទីនោះ ដែលកម្រិតការជូនដំណឹងខ្ពស់បំផុតត្រូវបានគេមិនអើពើ។ លើសពីនេះ ភាពងាយរងគ្រោះត្រូវពន្យល់តាមរបៀបដែលធ្វើឱ្យវាច្បាស់អំពីរបៀបដែលវាជះឥទ្ធិពលដល់អាជីវកម្ម។ ជាឧទាហរណ៍ អ្នកអាចនិយាយបានថា នេះគឺជាភាពងាយរងគ្រោះដូចគ្នាទៅនឹងរឿង Equifax ដែរ។ ភាពងាយរងគ្រោះផ្នែកសុវត្ថិភាពគួរតែត្រូវបានចាត់ទុកដូចគ្នានឹងបញ្ហាកម្មវិធីផ្សេងទៀតដែរ ពោលគឺពួកគេគួរតែត្រូវបានបញ្ចូលទៅក្នុងដំណើរការ DevOps ទាំងមូល។ អ្នកត្រូវធ្វើការជាមួយពួកគេតាមរយៈ Jira, Kanban ។ល។ អ្នកអភិវឌ្ឍន៍មិនគួរគិតថាអ្នកផ្សេងនឹងធ្វើបែបនេះទេ - ផ្ទុយទៅវិញ អ្នកគ្រប់គ្នាគួរតែធ្វើបែបនេះ។ ចុងក្រោយ អ្នកត្រូវចំណាយថាមពលលើការបណ្តុះបណ្តាលមនុស្ស។

តំណមានប្រយោជន៍

នេះគឺជាកិច្ចពិភាក្សាមួយចំនួនពីសន្និសិទ DevOops ដែលអ្នកអាចយល់ថាមានប្រយោជន៍៖

• Sergey Berdnikov, Artyom Kalichkin - រឿងជោគជ័យ ឬ "Dev+DevOps+Ops" (видео, ប្រតិចារិកនៃរបាយការណ៍)
• Baruch Sadogursky, Leonid Igolnik - DevOps នៅលើមាត្រដ្ឋាន៖ សោកនាដកម្មក្រិកនៅក្នុងអំពើបី (видео, ប្រតិចារិកនៃរបាយការណ៍)
• Alexander Titov, Kirill Tolkachev - DevOps វិស្វករ និងសហគមន៍
• Timothy Lister - តួអង្គ សហគមន៍ និងវប្បធម៌៖ កត្តាសំខាន់សម្រាប់ភាពរុងរឿង

រកមើល កម្មវិធី DevOops 2020 ទីក្រុងម៉ូស្គូ - មានរឿងគួរឱ្យចាប់អារម្មណ៍ជាច្រើននៅទីនោះ។

ប្រភព: www.habr.com