លោក Anton Weiss ស្ថាបនិក និងជានាយកនៃកម្មវិធី Otomato Software ដែលជាអ្នកផ្តួចផ្តើមគំនិត និងជាគ្រូបង្ហាត់នៃវិញ្ញាបនប័ត្រ DevOps ដំបូងបង្អស់ក្នុងប្រទេសអ៊ីស្រាអែល បាននិយាយនៅក្នុងកម្មវិធីកាលពីឆ្នាំមុន។ អំពីទ្រឹស្តីភាពវឹកវរ និងគោលការណ៍សំខាន់ៗនៃវិស្វកម្មភាពវឹកវរ ហើយក៏បានពន្យល់ពីរបៀបដែលអង្គការ DevOps ដ៏ល្អនាពេលអនាគតដំណើរការ។
យើងបានរៀបចំកំណែអត្ថបទនៃរបាយការណ៍។
អរុណសួស្តី
DevOpsDays នៅទីក្រុងមូស្គូសម្រាប់ឆ្នាំទីពីរជាប់ៗគ្នា នេះជាលើកទីពីររបស់ខ្ញុំនៅលើឆាកនេះ អ្នកទាំងអស់គ្នានៅក្នុងបន្ទប់នេះជាលើកទីពីរ។ តើវាមានន័យយ៉ាងដូចម្តេច? នេះមានន័យថាចលនា DevOps នៅក្នុងប្រទេសរុស្ស៊ីកំពុងកើនឡើង គុណ និងសំខាន់បំផុត វាមានន័យថាពេលវេលាបានមកដល់ដើម្បីនិយាយអំពីអ្វីដែល DevOps គឺនៅឆ្នាំ 2018 ។
លើកដៃអ្នកដែលគិតថា DevOps ជាវិជ្ជាជីវៈមួយនៅឆ្នាំ 2018? មានបែបនេះ។ តើមានវិស្វករ DevOps នៅក្នុងបន្ទប់ដែលការពិពណ៌នាការងារនិយាយថា "DevOps Engineer" ទេ? តើមានអ្នកគ្រប់គ្រង DevOps នៅក្នុងបន្ទប់ទេ? មិនមានបែបនោះទេ។ ស្ថាបត្យករ DevOps? ក៏មិនអីដែរ។ មិនគ្រប់គ្រាន់។ តើវាពិតជាពិតទេដែលគ្មាននរណាម្នាក់និយាយថាពួកគេជាវិស្វករ DevOps?
ដូច្នេះអ្នកភាគច្រើនគិតថានេះជាការប្រឆាំងនឹងគំរូ? វិជ្ជាជីវៈបែបនេះមិនគួរមានទេ? យើងអាចគិតអ្វីក៏ដោយដែលយើងចង់បាន ប៉ុន្តែខណៈពេលដែលយើងកំពុងគិត ឧស្សាហកម្មនេះកំពុងឆ្ពោះទៅមុខយ៉ាងឱឡារិកចំពោះសំឡេងត្រែរបស់ DevOps ។
អ្នកណាខ្លះបានលឺអំពីប្រធានបទថ្មីដែលមានឈ្មោះថា DevDevOps? នេះគឺជាបច្ចេកទេសថ្មីមួយដែលអនុញ្ញាតឱ្យមានការសហការប្រកបដោយប្រសិទ្ធភាពរវាងអ្នកអភិវឌ្ឍន៍ និង devops ។ ហើយមិនមែនថ្មីប៉ុន្មានទេ។ ដោយវិនិច្ឆ័យតាម Twitter ពួកគេបានចាប់ផ្តើមនិយាយអំពីរឿងនេះរួចហើយកាលពី 4 ឆ្នាំមុន។ ហើយរហូតមកដល់ពេលនេះការចាប់អារម្មណ៍លើរឿងនេះកំពុងកើនឡើងនិងរីកចម្រើនពោលគឺមានបញ្ហា។ បញ្ហាត្រូវតែដោះស្រាយ។
យើងជាមនុស្សមានគំនិតច្នៃប្រឌិត យើងមិនគ្រាន់តែសម្រាកស្រួលនោះទេ។ យើងនិយាយថា៖ DevOps មិនមែនជាពាក្យទូលំទូលាយគ្រប់គ្រាន់ទេ វានៅតែខ្វះធាតុប្លែកៗ និងគួរឱ្យចាប់អារម្មណ៍ទាំងអស់។ ហើយយើងទៅមន្ទីរពិសោធន៍សម្ងាត់របស់យើង ហើយចាប់ផ្តើមបង្កើតការផ្លាស់ប្តូរគួរឱ្យចាប់អារម្មណ៍៖ DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps ។
តក្កវិជ្ជាគឺជាការបិទដែកមែនទេ? ប្រព័ន្ធចែកចាយរបស់យើងមិនដំណើរការទេ ប្រព័ន្ធរបស់យើងមិនស្ថិតស្ថេរ ហើយអ្នកប្រើប្រាស់របស់យើងមិនពេញចិត្ត យើងមិនមានពេលដើម្បីដាក់ចេញកម្មវិធីទាន់ពេលទេ យើងមិនសមនឹងថវិកា។ តើយើងនឹងដោះស្រាយបញ្ហាទាំងអស់នេះដោយរបៀបណា? យើងនឹងចេញពាក្យថ្មី! វានឹងបញ្ចប់ដោយ "Ops" ហើយបញ្ហាត្រូវបានដោះស្រាយ។
ដូច្នេះខ្ញុំហៅវិធីនេះថា "អូប ហើយបញ្ហាត្រូវបានដោះស្រាយ"។
ទាំងអស់នេះនឹងរលត់ទៅផ្ទៃខាងក្រោយ ប្រសិនបើយើងរំលឹកខ្លួនយើងថាហេតុអ្វីបានជាយើងបង្កើតរឿងទាំងអស់នេះ។ យើងបានបង្កើតឡើងនូវរឿង DevOps ទាំងមូលនេះដើម្បីធ្វើឱ្យការផ្តល់កម្មវិធី និងការងារផ្ទាល់ខ្លួនរបស់យើងនៅក្នុងដំណើរការនេះដោយមិនមានការរារាំង គ្មានការឈឺចាប់ មានប្រសិទ្ធភាព ហើយសំខាន់បំផុតគឺរីករាយតាមដែលអាចធ្វើទៅបាន។
DevOps កើតចេញពីការឈឺចាប់។ ហើយយើងធុញទ្រាន់នឹងការរងទុក្ខ។ ហើយដើម្បីឱ្យអ្វីៗទាំងអស់នេះកើតឡើង យើងពឹងផ្អែកលើការអនុវត្តបៃតង៖ កិច្ចសហការប្រកបដោយប្រសិទ្ធភាព ការអនុវត្តលំហូរ និងសំខាន់បំផុតគឺការគិតជាប្រព័ន្ធ ពីព្រោះបើគ្មានវាទេ DevOps មិនដំណើរការទេ។
តើប្រព័ន្ធជាអ្វី?
ហើយប្រសិនបើយើងកំពុងនិយាយអំពីប្រព័ន្ធគិតរួចហើយ ចូររំលឹកខ្លួនយើងថាប្រព័ន្ធមួយជាអ្វី។
ប្រសិនបើអ្នកជា hacker បដិវត្តន៍ នោះប្រព័ន្ធគឺច្បាស់ណាស់សម្រាប់អ្នក។ វាជាពពកដែលព្យួរលើអ្នក ហើយបង្ខំអ្នកឱ្យធ្វើអ្វីដែលអ្នកមិនចង់ធ្វើ។
តាមទស្សនៈនៃការគិតប្រព័ន្ធ ប្រព័ន្ធគឺទាំងមូលដែលមានផ្នែក។ ក្នុងន័យនេះ យើងម្នាក់ៗគឺជាប្រព័ន្ធមួយ។ អង្គការដែលយើងធ្វើការជាប្រព័ន្ធ។ ហើយអ្វីដែលអ្នកនិងខ្ញុំកំពុងសាងសង់ត្រូវបានគេហៅថាប្រព័ន្ធ។
ទាំងអស់នេះគឺជាផ្នែកមួយនៃប្រព័ន្ធសង្គមបច្ចេកវិទ្យាដ៏ធំមួយ។ ហើយប្រសិនបើយើងយល់ពីរបៀបដែលប្រព័ន្ធបច្ចេកវិទ្យាសង្គមនេះដំណើរការជាមួយគ្នា នោះមានតែយើងទេដែលនឹងអាចបង្កើនប្រសិទ្ធភាពពិតប្រាកដនៅក្នុងបញ្ហានេះ។
តាមទស្សនៈនៃប្រព័ន្ធគិត ប្រព័ន្ធមួយមានលក្ខណៈសម្បត្តិគួរឱ្យចាប់អារម្មណ៍ផ្សេងៗ។ ទីមួយវាមានផ្នែកដែលមានន័យថាអាកប្បកិរិយារបស់វាអាស្រ័យលើឥរិយាបថនៃផ្នែក។ ជាងនេះទៅទៀត ផ្នែកទាំងអស់របស់វាក៏អាស្រ័យគ្នាទៅវិញទៅមកផងដែរ។ វាបង្ហាញថាប្រព័ន្ធមួយមានផ្នែកកាន់តែច្រើន វាកាន់តែពិបាកយល់ ឬទស្សន៍ទាយឥរិយាបថរបស់វា។
តាមទស្សនៈនៃអាកប្បកិរិយា មានការពិតគួរឱ្យចាប់អារម្មណ៍មួយទៀត។ ប្រព័ន្ធអាចធ្វើអ្វីមួយដែលគ្មានផ្នែកនីមួយៗរបស់វាអាចធ្វើបាន។
ដូចដែលលោកវេជ្ជបណ្ឌិត Russell Ackoff (ស្ថាបនិកម្នាក់នៃការបង្កើតប្រព័ន្ធគិត) បាននិយាយថា នេះពិតជាងាយស្រួលណាស់ក្នុងការបញ្ជាក់ដោយការពិសោធន៍ការគិតមួយ។ ជាឧទាហរណ៍ តើអ្នកណានៅក្នុងបន្ទប់ចេះសរសេរកូដ? មានដៃច្រើន ហើយនេះជារឿងធម្មតាទេ ព្រោះនេះជាតម្រូវការសំខាន់មួយសម្រាប់វិជ្ជាជីវៈរបស់យើង។ តើអ្នកដឹងពីរបៀបសរសេរ ប៉ុន្តែដៃរបស់អ្នកអាចសរសេរកូដដាច់ដោយឡែកពីអ្នកបានទេ? មានមនុស្សដែលនឹងនិយាយថា “វាមិនមែនជាដៃរបស់ខ្ញុំដែលសរសេរកូដនោះទេ វាគឺជាខួរក្បាលរបស់ខ្ញុំដែលសរសេរកូដ”។ តើខួរក្បាលរបស់អ្នកអាចសរសេរកូដដាច់ដោយឡែកពីអ្នកបានទេ? ប្រហែលមិនមែនទេ។
ខួរក្បាលគឺជាម៉ាស៊ីនដ៏អស្ចារ្យមួយ យើងមិនដឹងសូម្បីតែ 10% នៃរបៀបដែលវាដំណើរការនៅទីនោះ ប៉ុន្តែវាមិនអាចដំណើរការដាច់ដោយឡែកពីប្រព័ន្ធដែលជារាងកាយរបស់យើងបានទេ។ ហើយនេះជាការងាយស្រួលក្នុងការបញ្ជាក់៖ បើកលលាដ៍ក្បាលរបស់អ្នក យកខួរក្បាលរបស់អ្នកចេញ ដាក់វានៅមុខកុំព្យូទ័រ ឱ្យគាត់ព្យាយាមសរសេរអ្វីដែលសាមញ្ញ។ ឧទាហរណ៍ "ជំរាបសួរពិភពលោក" នៅក្នុង Python ។
ប្រសិនបើប្រព័ន្ធមួយអាចធ្វើអ្វីមួយដែលគ្មានផ្នែករបស់វាអាចធ្វើបានដោយឡែកពីគ្នា នោះមានន័យថាឥរិយាបថរបស់វាមិនត្រូវបានកំណត់ដោយឥរិយាបថនៃផ្នែករបស់វានោះទេ។ តើវាត្រូវបានកំណត់ដោយអ្វី? វាត្រូវបានកំណត់ដោយអន្តរកម្មរវាងផ្នែកទាំងនេះ។ ហើយតាមនោះ ផ្នែកកាន់តែច្រើន អន្តរកម្មកាន់តែស្មុគស្មាញ វាកាន់តែពិបាកយល់ និងទស្សន៍ទាយឥរិយាបថនៃប្រព័ន្ធ។ ហើយនេះធ្វើឱ្យប្រព័ន្ធមានភាពច្របូកច្របល់ ពីព្រោះការផ្លាស់ប្តូរដែលមើលមិនឃើញ សូម្បីតែមិនសំខាន់បំផុត និងមើលមិនឃើញនៅក្នុងផ្នែកណាមួយនៃប្រព័ន្ធអាចនាំទៅរកលទ្ធផលដែលមិនអាចទាយទុកជាមុនបានទាំងស្រុង។
ភាពរសើបនេះចំពោះលក្ខខណ្ឌដំបូងត្រូវបានគេរកឃើញនិងសិក្សាដោយអ្នកឧតុនិយមជនជាតិអាមេរិក Ed Lorenz។ ក្រោយមកវាត្រូវបានគេហៅថា "ឥទ្ធិពលមេអំបៅ" ហើយបាននាំឱ្យមានការវិវត្តនៃចលនានៃការគិតបែបវិទ្យាសាស្ត្រដែលហៅថា "ទ្រឹស្តីវឹកវរ" ។ ទ្រឹស្ដីនេះបានក្លាយជាការផ្លាស់ប្តូរគំរូដ៏សំខាន់មួយនៅក្នុងវិទ្យាសាស្ត្រសតវត្សទី 20 ។
ទ្រឹស្តីភាពវឹកវរ
អ្នកដែលសិក្សាពីភាពវឹកវរ ហៅខ្លួនឯងថាជាអ្នកវឹកវរ។
តាមពិត ហេតុផលសម្រាប់របាយការណ៍នេះគឺថា ធ្វើការជាមួយប្រព័ន្ធចែកចាយដ៏ស្មុគស្មាញ និងអង្គការអន្តរជាតិធំៗ នៅចំណុចខ្លះខ្ញុំបានដឹងថានេះជាអ្វីដែលខ្ញុំមានអារម្មណ៍។ ខ្ញុំជាអ្នកវឹកវរ។ នេះជាមធ្យោបាយដ៏ឆ្លាតវៃក្នុងការនិយាយថា៖ "ខ្ញុំមិនយល់ពីអ្វីដែលកំពុងកើតឡើងនៅទីនេះ ហើយខ្ញុំមិនដឹងថាត្រូវធ្វើអ្វីអំពីវា"។
ខ្ញុំគិតថា អ្នកជាច្រើនក៏តែងមានអារម្មណ៍បែបនេះដែរ ដូច្នេះអ្នកក៏ជាអ្នកវឹកវរដែរ។ ខ្ញុំសូមអញ្ជើញអ្នកទៅកាន់ Guild of Chaosologists ។ ប្រព័ន្ធដែលអ្នក និងខ្ញុំ អ្នកជំនាញផ្នែកចលាចលជាទីគោរព នឹងសិក្សាត្រូវបានគេហៅថា "ប្រព័ន្ធបន្សាំស្មុគស្មាញ"។
តើអ្វីទៅជាការសម្របខ្លួន? អាដាប់ធ័រមានន័យថា អាកប្បកិរិយាបុគ្គល និងសមូហភាពនៃផ្នែកនៅក្នុងប្រព័ន្ធបន្សាំបែបនេះផ្លាស់ប្តូរ និងរៀបចំដោយខ្លួនឯង ឆ្លើយតបទៅនឹងព្រឹត្តិការណ៍ ឬខ្សែសង្វាក់នៃព្រឹត្តិការណ៍តូចៗនៅក្នុងប្រព័ន្ធ។ នោះគឺប្រព័ន្ធសម្របខ្លួនទៅនឹងការផ្លាស់ប្តូរតាមរយៈការរៀបចំខ្លួនឯង។ ហើយសមត្ថភាពក្នុងការរៀបចំដោយខ្លួនឯងនេះគឺផ្អែកលើការស្ម័គ្រចិត្ត និងកិច្ចសហប្រតិបត្តិការវិមជ្ឈការទាំងស្រុងរបស់ភ្នាក់ងារស្វយ័តសេរី។
ទ្រព្យសម្បត្តិគួរឱ្យចាប់អារម្មណ៍មួយទៀតនៃប្រព័ន្ធបែបនេះគឺថាពួកវាអាចធ្វើមាត្រដ្ឋានបានដោយសេរី។ អ្វីដែលគួរឲ្យចាប់អារម្មណ៍យើងជាអ្នកវឹកវរវិស្វករ។ ដូច្នេះ ប្រសិនបើយើងនិយាយថា ឥរិយាបថនៃប្រព័ន្ធស្មុគស្មាញត្រូវបានកំណត់ដោយអន្តរកម្មនៃផ្នែករបស់វា តើយើងគួរចាប់អារម្មណ៍លើអ្វី? អន្តរកម្ម។
មានការរកឃើញគួរឱ្យចាប់អារម្មណ៍ពីរបន្ថែមទៀត។
ទីមួយ យើងយល់ថាប្រព័ន្ធស្មុគស្មាញមិនអាចធ្វើឱ្យសាមញ្ញបានដោយការធ្វើឱ្យផ្នែករបស់វាកាន់តែងាយស្រួលនោះទេ។ ទីពីរ វិធីតែមួយគត់ដើម្បីធ្វើឱ្យប្រព័ន្ធស្មុគ្រស្មាញសាមញ្ញគឺដោយការធ្វើឱ្យអន្តរកម្មរវាងផ្នែករបស់វា។
តើយើងធ្វើអន្តរកម្មដោយរបៀបណា? អ្នក និងខ្ញុំគឺជាផ្នែកទាំងអស់នៃប្រព័ន្ធព័ត៌មានដ៏ធំមួយដែលហៅថាសង្គមមនុស្ស។ យើងប្រាស្រ័យទាក់ទងគ្នាតាមរយៈភាសាសាមញ្ញ ប្រសិនបើយើងមានវា ប្រសិនបើយើងរកឃើញវា។
ប៉ុន្តែភាសាខ្លួនឯងគឺជាប្រព័ន្ធសម្របខ្លួនដ៏ស្មុគស្មាញមួយ។ ដូច្នោះហើយ ដើម្បីធ្វើអន្តរកម្មកាន់តែមានប្រសិទ្ធភាព និងសាមញ្ញ យើងត្រូវបង្កើតពិធីការមួយចំនួន។ នោះគឺជាលំដាប់នៃនិមិត្តសញ្ញា និងសកម្មភាពមួយចំនួនដែលនឹងធ្វើឱ្យការផ្លាស់ប្តូរព័ត៌មានរវាងយើងកាន់តែសាមញ្ញ ងាយទាយ យល់បានកាន់តែច្រើន។
ខ្ញុំចង់និយាយថា និន្នាការឆ្ពោះទៅរកភាពស្មុគស្មាញ ឆ្ពោះទៅរកការសម្របខ្លួន ឆ្ពោះទៅវិមជ្ឈការ ឆ្ពោះទៅរកភាពចលាចល អាចត្រូវបានតាមដាននៅក្នុងអ្វីគ្រប់យ៉ាង។ ហើយនៅក្នុងប្រព័ន្ធដែលអ្នក និងខ្ញុំកំពុងសាងសង់ ហើយនៅក្នុងប្រព័ន្ធទាំងនោះដែលយើងជាផ្នែកមួយ។
ហើយដើម្បីកុំឱ្យមានមូលដ្ឋាននោះ ចូរយើងក្រឡេកមើលរបៀបដែលប្រព័ន្ធដែលយើងបង្កើតកំពុងផ្លាស់ប្តូរ។
អ្នកកំពុងរង់ចាំពាក្យនេះ ខ្ញុំយល់ហើយ។ យើងនៅក្នុងសន្និសិទ DevOps ថ្ងៃនេះពាក្យនេះនឹងត្រូវបានឮប្រហែលមួយរយពាន់ដង ហើយបន្ទាប់មកយើងនឹងសុបិនអំពីវានៅពេលយប់។
Microservices គឺជាស្ថាបត្យកម្មកម្មវិធីដំបូងគេដែលលេចចេញជាប្រតិកម្មចំពោះការអនុវត្ត DevOps ដែលត្រូវបានរចនាឡើងដើម្បីធ្វើឱ្យប្រព័ន្ធរបស់យើងកាន់តែមានភាពបត់បែន ធ្វើមាត្រដ្ឋានកាន់តែច្រើន និងធានាបាននូវការចែកចាយបន្ត។ តើនាងធ្វើបែបនេះដោយរបៀបណា? តាមរយៈការកាត់បន្ថយបរិមាណនៃសេវាកម្ម កាត់បន្ថយវិសាលភាពនៃបញ្ហាដែលសេវាកម្មទាំងនេះដំណើរការ កាត់បន្ថយពេលវេលាដឹកជញ្ជូន។ នោះគឺយើងកាត់បន្ថយ និងសម្រួលផ្នែកនៃប្រព័ន្ធ បង្កើនចំនួនរបស់ពួកគេ ហើយតាមនោះ ភាពស្មុគស្មាញនៃអន្តរកម្មរវាងផ្នែកទាំងនេះកើនឡើងជាលំដាប់ ពោលគឺបញ្ហាថ្មីកើតឡើងដែលយើងត្រូវដោះស្រាយ។
Microservices មិនមែនជាទីបញ្ចប់ទេ ជាទូទៅ សេវាមីក្រូគឺរួចហើយកាលពីម្សិលមិញ ព្រោះ Serverless នឹងមកដល់។ ម៉ាស៊ីនមេទាំងអស់ត្រូវបានដុតបំផ្លាញ គ្មានម៉ាស៊ីនមេ គ្មានប្រព័ន្ធប្រតិបត្តិការ គ្រាន់តែជាកូដដែលអាចប្រតិបត្តិបានសុទ្ធ។ ការកំណត់រចនាសម្ព័ន្ធគឺដាច់ដោយឡែក រដ្ឋគឺដាច់ដោយឡែក អ្វីគ្រប់យ៉ាងត្រូវបានគ្រប់គ្រងដោយព្រឹត្តិការណ៍។ សោភ័ណភាព ភាពស្អាតស្អំ ស្ងប់ស្ងាត់ គ្មានព្រឹត្តិការណ៍អ្វីកើតឡើង សណ្តាប់ធ្នាប់ពេញលេញ។
តើភាពស្មុគស្មាញនៅឯណា? ពិតណាស់ការលំបាកគឺស្ថិតនៅក្នុងអន្តរកម្ម។ តើមុខងារមួយអាចធ្វើដោយខ្លួនឯងបានប៉ុន្មាន? តើវាមានអន្តរកម្មជាមួយមុខងារផ្សេងទៀតយ៉ាងដូចម្តេច? ជួរសារ មូលដ្ឋានទិន្នន័យ តុល្យភាព។ តើធ្វើដូចម្តេចដើម្បីបង្កើតព្រឹត្តិការណ៍មួយចំនួននៅពេលដែលបរាជ័យបានកើតឡើង? សំណួរជាច្រើន និងចម្លើយតិចតួច។
Microservices និង Serverless គឺជាអ្វីដែលយើងហៅថា Cloud Native។ វាទាំងអស់អំពីពពក។ ប៉ុន្តែពពកក៏ត្រូវបានកំណត់ក្នុងការធ្វើមាត្រដ្ឋានរបស់វាដែរ។ យើងធ្លាប់គិតថាវាជាប្រព័ន្ធចែកចាយ។ តាមពិត តើម៉ាស៊ីនមេរបស់អ្នកផ្តល់សេវាពពករស់នៅឯណា? នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ។ នោះគឺជា យើងមានប្រភេទនៃគំរូចែកចាយនៅកណ្តាល ដែលមានកម្រិតខ្លាំង។
សព្វថ្ងៃនេះ យើងយល់ថា Internet of Things លែងគ្រាន់តែជាពាក្យធំៗ ដែលសូម្បីតែតាមការព្យាករណ៍តិចតួចក៏ដោយ ឧបករណ៍រាប់លានដែលភ្ជាប់អ៊ីនធឺណិតកំពុងរង់ចាំយើងក្នុងរយៈពេល XNUMX ទៅ XNUMX ឆ្នាំខាងមុខ។ ចំនួនដ៏ច្រើននៃទិន្នន័យដែលមានប្រយោជន៍ និងគ្មានប្រយោជន៍ដែលនឹងត្រូវបានបញ្ចូលទៅក្នុងពពក ហើយបង្ហោះពីពពក។
ពពកនឹងមិនស្ថិតស្ថេរទេ ដូច្នេះយើងកំពុងនិយាយកាន់តែខ្លាំងឡើងអំពីអ្វីដែលហៅថា edge computing។ ឬខ្ញុំក៏ចូលចិត្តនិយមន័យដ៏អស្ចារ្យនៃ "កុំព្យូទ័រអ័ព្ទ"។ វាត្រូវបានគ្របដណ្ដប់ដោយអាថ៌កំបាំងនៃមនោសញ្ចេតនា និងអាថ៌កំបាំង។
ការគណនាអ័ព្ទ។ ចំណុចនោះគឺថា ពពកគឺជាបណ្តុំកណ្តាលនៃទឹក ចំហាយទឹក ទឹកកក និងថ្ម។ ហើយអ័ព្ទគឺជាដំណក់ទឹកដែលរាយប៉ាយនៅជុំវិញយើងនៅក្នុងបរិយាកាស។
នៅក្នុងគំរូអ័ព្ទ ការងារភាគច្រើនត្រូវបានធ្វើដោយដំណក់ទឹកទាំងនេះដោយស្វ័យភាពទាំងស្រុង ឬដោយសហការជាមួយនឹងដំណក់ទឹកផ្សេងទៀត។ ហើយពួកគេបែរទៅពពកតែពេលដែលពួកគេពិតជាត្រូវបានគេចុចពិតប្រាកដ។
នោះគឺជាវិមជ្ឈការ ស្វ័យភាព ហើយជាការពិតណាស់ អ្នកទាំងអស់គ្នាបានយល់រួចហើយថា អ្វីៗទាំងអស់នេះនឹងទៅជាយ៉ាងណា ពីព្រោះអ្នកមិនអាចនិយាយអំពីវិមជ្ឈការដោយមិននិយាយអំពី blockchain បានទេ។
មានអ្នកដែលជឿ ទាំងនេះគឺជាអ្នកដែលបានបណ្តាក់ទុនក្នុងរូបិយប័ណ្ណគ្រីបតូ។ មានអ្នកដែលជឿតែខ្លាចដូចខ្ញុំជាឧទាហរណ៍។ ហើយមានអ្នកដែលមិនជឿ។ នៅទីនេះអ្នកអាចព្យាបាលខុសគ្នា។ មានបច្ចេកវិទ្យា រឿងមិនស្គាល់ថ្មីមានបញ្ហា។ ដូចជាបច្ចេកវិទ្យាថ្មីណាក៏ដោយ វាបង្កើតសំណួរច្រើនជាងចម្លើយ។
ការឃោសនាបំផ្លើសជុំវិញ blockchain គឺអាចយល់បាន។ ការប្រញាប់ប្រញាល់មាសមួយឡែក បច្ចេកវិទ្យាខ្លួនវាមានការសន្យាគួរឱ្យកត់សម្គាល់សម្រាប់អនាគតដ៏ត្រចះត្រចង់៖ សេរីភាពកាន់តែច្រើន ស្វ័យភាពកាន់តែច្រើន ការចែកចាយការជឿទុកចិត្តជាសកល។ អ្វីដែលមិនចង់?
ដូច្នោះហើយ វិស្វករកាន់តែច្រើនឡើងនៅជុំវិញពិភពលោកកំពុងចាប់ផ្តើមបង្កើតកម្មវិធីវិមជ្ឈការ។ ហើយនេះគឺជាអំណាចដែលមិនអាចបដិសេធបានដោយគ្រាន់តែនិយាយថា: "Ahh, blockchain គ្រាន់តែជាមូលដ្ឋានទិន្នន័យដែលបានចែកចាយតិចតួចប៉ុណ្ណោះ" ។ ឬដូចដែលអ្នកសង្ស័យចូលចិត្តនិយាយថា "មិនមានកម្មវិធីពិតប្រាកដសម្រាប់ blockchain ទេ" ។ ប្រសិនបើអ្នកគិតអំពីវា 150 ឆ្នាំមុនពួកគេបាននិយាយដូចគ្នាអំពីអគ្គិសនី។ ហើយពួកគេថែមទាំងត្រឹមត្រូវតាមវិធីខ្លះ ពីព្រោះអ្វីដែលអគ្គិសនីអាចធ្វើទៅបាននាពេលបច្ចុប្បន្ននេះ គឺមិនអាចទៅរួចក្នុងសតវត្សទី 19 នោះទេ។
និយាយអីញ្ចឹង តើអ្នកណាដឹងថាឡូហ្គោប្រភេទណានៅលើអេក្រង់? នេះគឺជា Hyperledger ។ នេះគឺជាគម្រោងមួយដែលកំពុងត្រូវបានបង្កើតឡើងក្រោមការឧបត្ថម្ភរបស់មូលនិធិលីនុច និងរួមបញ្ចូលនូវបណ្តុំនៃបច្ចេកវិទ្យា blockchain ។ នេះពិតជាកម្លាំងនៃសហគមន៍ប្រភពបើកចំហរបស់យើង។
វិស្វកម្ម Chaos
ដូច្នេះ ប្រព័ន្ធដែលយើងកំពុងអភិវឌ្ឍកាន់តែស្មុគស្មាញ កាន់តែច្របូកច្របល់ និងកាន់តែប្រែប្រួលទៅៗ។ ក្រុមហ៊ុន Netflix គឺជាអ្នកត្រួសត្រាយផ្លូវនៃប្រព័ន្ធមីក្រូសេវាកម្ម។ ពួកគេស្ថិតក្នុងចំណោមអ្នកដំបូងដែលយល់អំពីរឿងនេះ ពួកគេបានបង្កើតឧបករណ៍ដែលពួកគេហៅថា Simian Army ដែលល្បីល្បាញជាងគេ . គាត់បានកំណត់អ្វីដែលត្រូវបានគេស្គាល់ថាជា .
ដោយវិធីនេះ នៅក្នុងដំណើរការនៃការធ្វើការលើរបាយការណ៍ យើងថែមទាំងបានបកប្រែអត្ថបទនេះទៅជាភាសារុស្សី ដូច្នេះសូមចូលទៅកាន់ , អាន, បញ្ចេញមតិ, ស្តីបន្ទោស។
ដោយសង្ខេបគោលការណ៍នៃវិស្វកម្មវឹកវរនិយាយដូចខាងក្រោម។ ប្រព័ន្ធចែកចាយស្មុគ្រស្មាញគឺមិនអាចទាយទុកជាមុនបាន និងជាកំហុសដោយធម្មជាតិ។ កំហុសគឺជៀសមិនរួច ដែលមានន័យថាយើងត្រូវទទួលយកកំហុសទាំងនេះ ហើយធ្វើការជាមួយប្រព័ន្ធទាំងនេះតាមរបៀបខុសគ្នាទាំងស្រុង។
ខ្លួនយើងផ្ទាល់ត្រូវតែព្យាយាមណែនាំកំហុសទាំងនេះទៅក្នុងប្រព័ន្ធផលិតកម្មរបស់យើង ដើម្បីសាកល្បងប្រព័ន្ធរបស់យើងសម្រាប់ការសម្របខ្លួនដូចគ្នានេះ សមត្ថភាពសម្រាប់ការរៀបចំដោយខ្លួនឯង ដើម្បីការរស់រានមានជីវិត។
ហើយវាផ្លាស់ប្តូរអ្វីៗទាំងអស់។ មិនត្រឹមតែរបៀបដែលយើងដាក់ឱ្យដំណើរការប្រព័ន្ធក្នុងការផលិតប៉ុណ្ណោះទេ ប៉ុន្តែក៏របៀបដែលយើងអភិវឌ្ឍវា របៀបដែលយើងសាកល្បងពួកវា។ មិនមានដំណើរការនៃស្ថេរភាពឬការបង្កកនៃកូដទេ ផ្ទុយទៅវិញ មានដំណើរការថេរនៃអស្ថិរភាព។ យើងកំពុងព្យាយាមសម្លាប់ប្រព័ន្ធនេះ ហើយឃើញវាបន្តរស់រានមានជីវិត។
ពិធីការរួមបញ្ចូលប្រព័ន្ធដែលបានចែកចាយ
ដូច្នោះហើយ វាទាមទារឱ្យប្រព័ន្ធរបស់យើងផ្លាស់ប្តូរដូចម្ដេច។ ដើម្បីឱ្យពួកគេមានស្ថេរភាពជាងមុន ពួកគេត្រូវការពិធីការថ្មីមួយចំនួនសម្រាប់អន្តរកម្មរវាងផ្នែករបស់ពួកគេ។ ដូច្នេះផ្នែកទាំងនេះអាចយល់ស្របនិងមកដល់ប្រភេទនៃការរៀបចំខ្លួនឯង។ ហើយឧបករណ៍ថ្មីគ្រប់ប្រភេទ ពិធីការថ្មីកើតឡើង ដែលខ្ញុំហៅថា “ពិធីការសម្រាប់អន្តរកម្មនៃប្រព័ន្ធចែកចាយ”។
តើខ្ញុំកំពុងនិយាយអំពីអ្វី? ទីមួយ គម្រោង . ខ្លះព្យាយាមបង្កើតពិធីការតាមដានការចែកចាយទូទៅ ដែលជាឧបករណ៍មិនអាចខ្វះបានសម្រាប់ការបំបាត់កំហុសប្រព័ន្ធចែកចាយស្មុគស្មាញ។
បន្ថែមទៀត - . យើងនិយាយថា យើងមិនអាចទស្សន៍ទាយបានថានឹងមានអ្វីកើតឡើងចំពោះប្រព័ន្ធនោះទេ ពោលគឺយើងត្រូវបង្កើនការសង្កេត ការសង្កេតរបស់វា។ Opentracing ជាកម្មសិទ្ធិរបស់ក្រុមឧបករណ៍ដែលផ្តល់ឱ្យការសង្កេតដល់ប្រព័ន្ធរបស់យើង។ ប៉ុន្តែយើងត្រូវការការសង្កេតដើម្បីកំណត់ថាតើប្រព័ន្ធដំណើរការដូចដែលយើងរំពឹងទុកឬអត់។ តើយើងកំណត់ឥរិយាបទដែលរំពឹងទុកដោយរបៀបណា? ដោយកំណត់ប្រភេទនៃគោលនយោបាយមួយចំនួន ការកំណត់មួយចំនួន។ គម្រោងភ្នាក់ងារគោលនយោបាយបើកចំហកំពុងធ្វើការដើម្បីកំណត់សំណុំនៃច្បាប់នេះនៅទូទាំងវិសាលគមចាប់ពីការចូលដំណើរការទៅការបែងចែកធនធាន។
ដូចដែលយើងបាននិយាយ ប្រព័ន្ធរបស់យើងត្រូវបានជំរុញដោយព្រឹត្តិការណ៍កាន់តែខ្លាំងឡើង។ Serverless គឺជាឧទាហរណ៍ដ៏អស្ចារ្យមួយនៃប្រព័ន្ធដែលជំរុញដោយព្រឹត្តិការណ៍។ ដើម្បីឱ្យយើងផ្ទេរព្រឹត្តិការណ៍រវាងប្រព័ន្ធ និងតាមដានពួកវា យើងត្រូវការភាសាសាមញ្ញមួយចំនួន ពិធីការទូទៅមួយចំនួនសម្រាប់របៀបដែលយើងនិយាយអំពីព្រឹត្តិការណ៍ របៀបដែលយើងបញ្ជូនវាទៅគ្នាទៅវិញទៅមក។ នេះគឺជាអ្វីដែលហៅថាគម្រោង .
ស្ទ្រីមថេរនៃការផ្លាស់ប្តូរដែលបោកបញ្ឆោតលើប្រព័ន្ធរបស់យើង ធ្វើឱ្យពួកវាមានស្ថិរភាព គឺជាស្ទ្រីមជាបន្តបន្ទាប់នៃវត្ថុបុរាណរបស់កម្មវិធី។ ដើម្បីឱ្យយើងរក្សាលំហូរនៃការផ្លាស់ប្តូរឥតឈប់ឈរនេះ យើងត្រូវការពិធីការទូទៅមួយចំនួន ដែលយើងអាចនិយាយអំពីវត្ថុបុរាណរបស់កម្មវិធី របៀបដែលវាត្រូវបានសាកល្បង និងអ្វីដែលការផ្ទៀងផ្ទាត់វាបានឆ្លងកាត់។ នេះគឺជាអ្វីដែលហៅថាគម្រោង . នោះគឺជាពិធីការទិន្នន័យមេតាទូទៅសម្រាប់វត្ថុបុរាណកម្មវិធី។
ហើយចុងក្រោយ ប្រសិនបើយើងចង់ឱ្យប្រព័ន្ធរបស់យើងមានភាពឯករាជ្យទាំងស្រុង សម្របខ្លួន និងរៀបចំដោយខ្លួនឯង យើងត្រូវផ្តល់ឱ្យពួកគេនូវសិទ្ធិកំណត់អត្តសញ្ញាណខ្លួនឯង។ គម្រោងហៅកាត់ នេះជាអ្វីដែលគាត់ធ្វើ។ នេះក៏ជាគម្រោងក្រោមការឧបត្ថម្ភរបស់ Cloud Native Computing Foundation ផងដែរ។
គម្រោងទាំងអស់នេះគឺនៅក្មេង ពួកគេសុទ្ធតែត្រូវការសេចក្ដីស្រឡាញ់របស់យើង សុពលភាពរបស់យើង។ នេះគឺជាប្រភពបើកចំហទាំងអស់ ការធ្វើតេស្តរបស់យើង ការអនុវត្តរបស់យើង។ ពួកគេបង្ហាញយើងពីកន្លែងដែលបច្ចេកវិទ្យាកំពុងធ្វើដំណើរ។
ប៉ុន្តែ DevOps មិនដែលនិយាយអំពីបច្ចេកវិទ្យាជាចម្បងនោះទេ វាតែងតែនិយាយអំពីការសហការគ្នារវាងមនុស្ស។ ហើយបើយើងចង់ឱ្យប្រព័ន្ធដែលយើងអភិវឌ្ឍឱ្យមានការផ្លាស់ប្តូរ នោះយើងត្រូវតែផ្លាស់ប្តូរ។ តាមពិត យើងកំពុងផ្លាស់ប្តូរយ៉ាងណាក៏ដោយ យើងមិនមានជម្រើសច្រើនទេ។
មានភាពអស្ចារ្យមួយ។ អ្នកនិពន្ធជនជាតិអង់គ្លេស Rachel Botsman ដែលក្នុងនោះនាងសរសេរអំពីការវិវត្តន៍នៃការជឿទុកចិត្តពេញមួយប្រវត្តិសាស្រ្តរបស់មនុស្សជាតិ។ នាងនិយាយថាដំបូងឡើយក្នុងសង្គមបុព្វកាលការទុកចិត្តគឺនៅក្នុងស្រុក ពោលគឺយើងទុកចិត្តតែអ្នកដែលយើងស្គាល់ផ្ទាល់។
បន្ទាប់មកមានរយៈពេលយូរណាស់ - ពេលវេលាងងឹតនៅពេលដែលការជឿទុកចិត្តត្រូវបានប្រមូលផ្តុំនៅពេលដែលយើងចាប់ផ្តើមជឿទុកចិត្តលើមនុស្សដែលយើងមិនស្គាល់ដោយផ្អែកលើការពិតដែលថាយើងជាកម្មសិទ្ធិរបស់ស្ថាប័នសាធារណៈឬរដ្ឋដូចគ្នា។
ហើយនេះគឺជាអ្វីដែលយើងឃើញនៅក្នុងពិភពសម័យទំនើបរបស់យើង៖ ការជឿទុកចិត្តត្រូវបានចែកចាយ និងវិមជ្ឈការកាន់តែច្រើនឡើង ហើយវាត្រូវបានផ្អែកលើសេរីភាពនៃលំហូរព័ត៌មាន លើភាពអាចរកបាននៃព័ត៌មាន។
ប្រសិនបើអ្នកគិតអំពីវា ភាពងាយស្រួលបំផុតនេះ ដែលធ្វើឱ្យការជឿទុកចិត្តនេះអាចធ្វើទៅបាន គឺជាអ្វីដែលអ្នក និងខ្ញុំកំពុងអនុវត្ត។ នេះមានន័យថា ទាំងវិធីដែលយើងសហការ និងវិធីដែលយើងធ្វើត្រូវតែផ្លាស់ប្តូរ ពីព្រោះអង្គការ IT ដែលមានឋានានុក្រមពីសម័យបុរាណលែងដំណើរការទៀតហើយ។ ពួកគេចាប់ផ្តើមស្លាប់។
មូលដ្ឋានគ្រឹះនៃអង្គការ DevOps
អង្គការ DevOps ដ៏ល្អនាពេលអនាគតគឺជាប្រព័ន្ធវិមជ្ឈការ និងសម្របខ្លួនដែលមានក្រុមស្វយ័ត ដែលនីមួយៗមានបុគ្គលស្វយ័ត។ ក្រុមទាំងនេះត្រូវបានខ្ចាត់ខ្ចាយនៅជុំវិញពិភពលោក ដោយសហការគ្នាប្រកបដោយប្រសិទ្ធភាពដោយប្រើទំនាក់ទំនងអសមកាល ដោយប្រើពិធីការទំនាក់ទំនងដែលមានតម្លាភាពខ្ពស់។ ស្អាតណាស់មែនទេ? អនាគតដ៏ស្រស់ស្អាតណាស់។
ប្រាកដណាស់ គ្មានអ្វីដែលអាចធ្វើទៅរួច បើគ្មានការផ្លាស់ប្តូរវប្បធម៌។ យើងត្រូវតែមានការផ្លាស់ប្តូរភាពជាអ្នកដឹកនាំ ការទទួលខុសត្រូវផ្ទាល់ខ្លួន ការលើកទឹកចិត្តផ្ទៃក្នុង។
នេះគឺជាមូលដ្ឋាននៃអង្គការ DevOps៖ តម្លាភាពព័ត៌មាន ទំនាក់ទំនងអសមកាល ភាពជាអ្នកដឹកនាំផ្លាស់ប្តូរ វិមជ្ឈការ។
ដុត
ប្រព័ន្ធដែលយើងជាផ្នែកមួយ និងប្រព័ន្ធដែលយើងបង្កើតមានភាពវឹកវរកាន់តែខ្លាំងឡើង ហើយវាពិបាកសម្រាប់មនុស្សយើងក្នុងការទប់ទល់នឹងគំនិតនេះ វាពិបាកក្នុងការបោះបង់ការបំភាន់នៃការគ្រប់គ្រង។ យើងព្យាយាមបន្តគ្រប់គ្រងពួកគេ ហើយវាជាញឹកញាប់នាំឱ្យអស់កម្លាំង។ ខ្ញុំនិយាយនេះតាមបទពិសោធន៍ផ្ទាល់ខ្លួន ខ្ញុំក៏ឆេះដែរ ខ្ញុំក៏ពិការដោយសារការបរាជ័យក្នុងផលិតកម្មដែលនឹកស្មានមិនដល់។
ការអស់កម្លាំងកើតឡើងនៅពេលដែលយើងព្យាយាមគ្រប់គ្រងអ្វីមួយដែលមិនអាចគ្រប់គ្រងបាន។ ពេលយើងឆេះអស់ហើយ អ្វីៗនឹងបាត់បង់អត្ថន័យដោយសារយើងបាត់បង់ការចង់ធ្វើអ្វីដែលថ្មី យើងទទួលបានការការពារ ហើយចាប់ផ្ដើមការពារនូវអ្វីដែលយើងមាន។
វិជ្ជាជីវៈវិស្វកម្ម ដូចដែលខ្ញុំតែងតែចង់រំលឹកខ្លួនឯង គឺជាវិជ្ជាជីវៈដំបូង និងសំខាន់បំផុត។ បើយើងបាត់បង់បំណងចង់បង្កើតអ្វីមួយ នោះយើងក្លាយទៅជាផេះ ប្រែទៅជាផេះ។ មនុស្សដុតចោល អង្គការទាំងមូលឆេះអស់។
តាមគំនិតរបស់ខ្ញុំ ការទទួលយកតែអំណាចច្នៃប្រឌិតនៃភាពវឹកវរ មានតែការកសាងកិច្ចសហប្រតិបត្តិការតាមគោលការណ៍របស់វាប៉ុណ្ណោះ ដែលជាអ្វីដែលនឹងជួយយើងមិនឱ្យបាត់បង់នូវអ្វីដែលល្អនៅក្នុងវិជ្ជាជីវៈរបស់យើង។
នេះជាអ្វីដែលខ្ញុំចង់ជូនពរអ្នក៖ ស្រឡាញ់ការងាររបស់អ្នក ស្រឡាញ់អ្វីដែលយើងធ្វើ។ ពិភពលោកនេះចិញ្ចឹមលើព័ត៌មាន យើងមានកិត្តិយសក្នុងការចិញ្ចឹមវា។ ដូច្នេះ ចូរយើងសិក្សាពីភាពវឹកវរ ចូរយើងធ្វើជាអ្នកវឹកវរ ចូរនាំតម្លៃ បង្កើតអ្វីដែលថ្មី ល្អ បញ្ហាដូចដែលយើងបានរកឃើញរួចមកហើយ គឺជៀសមិនរួច ហើយនៅពេលដែលវាលេចឡើង យើងនឹងនិយាយដោយសាមញ្ញថា "Ops!" ហើយបញ្ហាត្រូវបានដោះស្រាយ។ .
តើមានអ្វីក្រៅពី Chaos Monkey?
តាមពិតឧបករណ៍ទាំងអស់នេះនៅក្មេងណាស់។ Netflix ដូចគ្នាបានបង្កើតឧបករណ៍សម្រាប់ខ្លួនគេ។ បង្កើតឧបករណ៍ផ្ទាល់ខ្លួនរបស់អ្នក។ អានគោលការណ៍វិស្វកម្មភាពវឹកវរ ហើយរស់នៅតាមគោលការណ៍ទាំងនោះ ជាជាងការព្យាយាមស្វែងរកឧបករណ៍ផ្សេងទៀតដែលនរណាម្នាក់បានសាងសង់រួចហើយ។
ព្យាយាមស្វែងយល់ពីរបៀបដែលប្រព័ន្ធរបស់អ្នកខូច ហើយចាប់ផ្តើមបំបែកពួកវា ហើយមើលពីរបៀបដែលពួកគេទប់ទល់។ នេះមកមុន។ ហើយអ្នកអាចស្វែងរកឧបករណ៍។ មានគម្រោងគ្រប់ប្រភេទ។
ខ្ញុំមិនយល់ទាល់តែសោះនៅពេលដែលអ្នកបាននិយាយថាប្រព័ន្ធមិនអាចធ្វើឱ្យសាមញ្ញដោយការធ្វើឱ្យសមាសធាតុរបស់វាងាយស្រួលនោះទេ ហើយភ្លាមៗនោះបានបន្តទៅសេវាកម្មមីក្រូ ដែលធ្វើអោយប្រព័ន្ធមានភាពសាមញ្ញដោយការធ្វើឱ្យសមាសធាតុខ្លួនឯងមានភាពសាមញ្ញ និងធ្វើឱ្យអន្តរកម្មស្មុគស្មាញ។ ទាំងនេះគឺជាផ្នែកសំខាន់ពីរដែលផ្ទុយគ្នាទៅវិញទៅមក។
នោះជាការត្រឹមត្រូវ សេវាមីក្រូគឺជាប្រធានបទដ៏ចម្រូងចម្រាសជាទូទៅ។ ជាការពិត ការធ្វើឱ្យផ្នែកសាមញ្ញបង្កើនភាពបត់បែន។ តើសេវាកម្មមីក្រូផ្តល់អ្វីខ្លះ? ពួកគេផ្តល់ឱ្យយើងនូវភាពបត់បែន និងល្បឿន ប៉ុន្តែពួកគេប្រាកដជាមិនផ្តល់ឱ្យយើងនូវភាពសាមញ្ញនោះទេ។ ពួកគេបង្កើនការលំបាក។
ដូច្នេះនៅក្នុងទស្សនវិជ្ជា DevOps សេវាមីក្រូមិនមែនជារឿងល្អទេ?
ល្អណាមួយមានផ្នែកបញ្ច្រាស។ អត្ថប្រយោជន៍គឺថាវាបង្កើនភាពបត់បែនដែលអនុញ្ញាតឱ្យយើងធ្វើការផ្លាស់ប្តូរលឿនជាងមុនប៉ុន្តែវាបង្កើនភាពស្មុគស្មាញហើយដូច្នេះភាពផុយស្រួយនៃប្រព័ន្ធទាំងមូល។
ទោះយ៉ាងណា តើអ្វីជាការសង្កត់ធ្ងន់បន្ថែមទៀត៖ លើការធ្វើឱ្យអន្តរកម្មសាមញ្ញ ឬនៅលើផ្នែកដែលងាយស្រួល?
ជាការពិតណាស់ ការសង្កត់ធ្ងន់គឺលើការធ្វើឱ្យអន្តរកម្មងាយស្រួល ព្រោះប្រសិនបើយើងមើលពីចំណុចនៃទិដ្ឋភាពនៃរបៀបដែលយើងធ្វើការជាមួយអ្នក នោះជាដំបូង យើងត្រូវយកចិត្តទុកដាក់លើការធ្វើឱ្យអន្តរកម្មមានភាពសាមញ្ញ មិនមែនលើការធ្វើឱ្យការងារងាយស្រួលនោះទេ។ របស់យើងម្នាក់ៗដោយឡែកពីគ្នា។ ព្រោះការសម្រួលការងារមានន័យថាក្លាយជាមនុស្សយន្ត។ នៅទីនេះនៅ McDonald's វាដំណើរការជាធម្មតានៅពេលដែលអ្នកមានការណែនាំ៖ នៅទីនេះអ្នកដាក់ប៊ឺហ្គឺនៅទីនេះអ្នកចាក់ទឹកជ្រលក់លើវា។ នេះមិនដំណើរការទាល់តែសោះនៅក្នុងការងារច្នៃប្រឌិតរបស់យើង។
តើវាពិតទេដែលថា អ្វីៗដែលអ្នកបាននិយាយ រស់នៅក្នុងពិភពលោកដែលគ្មានការប្រកួតប្រជែង ហើយភាពវឹកវរនៅទីនោះគឺល្អណាស់ ហើយគ្មានភាពផ្ទុយគ្នានៅក្នុងភាពវឹកវរនេះ គ្មាននរណាម្នាក់ចង់ស៊ី ឬសម្លាប់នរណាម្នាក់ទេ? តើការប្រកួតប្រជែង និង DevOps គួរតែមានតម្លៃដូចម្តេច?
ជាការប្រសើរណាស់, វាអាស្រ័យលើប្រភេទនៃការប្រកួតប្រជែងដែលយើងកំពុងនិយាយអំពី។ តើវានិយាយអំពីការប្រកួតប្រជែងនៅកន្លែងធ្វើការ ឬការប្រកួតប្រជែងរវាងក្រុមហ៊ុន?
អំពីការប្រកួតប្រជែងនៃសេវាកម្មដែលមានដោយសារតែសេវាកម្មមិនមែនជាក្រុមហ៊ុនមួយចំនួន។ យើងកំពុងបង្កើតបរិយាកាសព័ត៌មានប្រភេទថ្មី ហើយបរិយាកាសណាមួយមិនអាចរស់នៅដោយគ្មានការប្រកួតប្រជែងបានទេ។ មានការប្រកួតប្រជែងនៅគ្រប់ទីកន្លែង។
Netflix ដូចគ្នា យើងយកពួកគេធ្វើជាគំរូ។ ហេតុអ្វីបានជាគេមករករឿងនេះ? ដោយសារតែពួកគេត្រូវការការប្រកួតប្រជែង។ ភាពបត់បែន និងល្បឿននៃចលនានេះពិតជាតម្រូវការប្រកួតប្រជែងខ្លាំងណាស់ វាបង្ហាញពីភាពវឹកវរទៅក្នុងប្រព័ន្ធរបស់យើង។ នោះគឺ ភាពវឹកវរមិនមែនជាអ្វីដែលយើងដឹងខ្លួនធ្វើដោយសារតែយើងចង់បាននោះទេ វាគឺជាអ្វីដែលកើតឡើងដោយសារតែពិភពលោកទាមទារវា។ យើងគ្រាន់តែត្រូវសម្របខ្លួនប៉ុណ្ណោះ។ និងភាពច្របូកច្របល់វាគឺជាលទ្ធផលនៃការប្រកួតប្រជែង។
តើនេះមានន័យថាភាពវឹកវរគឺជាអវត្តមាននៃគោលដៅដូចដែលវាមាន? ឬគោលដៅដែលយើងមិនចង់ឃើញ? យើងនៅក្នុងផ្ទះហើយមិនយល់ពីគោលដៅរបស់អ្នកដទៃ។ តាមពិតការប្រកួតប្រជែងគឺដោយសារតែយើងមានគោលដៅច្បាស់លាស់ ហើយយើងដឹងថាយើងនឹងបញ្ចប់នៅទីណានៅពេលបន្ទាប់នីមួយៗក្នុងពេលបន្ទាប់។ នេះតាមទស្សនៈរបស់ខ្ញុំ គឺជាខ្លឹមសារនៃ DevOps ។
សូមមើលសំណួរផងដែរ។ ខ្ញុំគិតថាយើងទាំងអស់គ្នាមានគោលដៅដូចគ្នា៖ ដើម្បីរស់ និងធ្វើវាជាមួយ
សេចក្តីរីករាយបំផុត។ ហើយគោលដៅប្រកួតប្រជែងរបស់ស្ថាប័នណាមួយគឺដូចគ្នា។ ការរស់រានមានជីវិតជារឿយៗកើតឡើងតាមរយៈការប្រកួតប្រជែង មិនមានអ្វីដែលអ្នកអាចធ្វើបានអំពីវាទេ។
សន្និសីទឆ្នាំនេះ នឹងប្រព្រឹត្តទៅនៅថ្ងៃទី 7 ខែធ្នូ នៅ Technopolis ។ យើងកំពុងទទួលពាក្យស្នើសុំរបាយការណ៍រហូតដល់ថ្ងៃទី 11 ខែវិច្ឆិកា។ យើងប្រសិនបើអ្នកចង់និយាយ។
ការចុះឈ្មោះសម្រាប់អ្នកចូលរួមត្រូវបានបើក សំបុត្រមានតម្លៃ 7000 រូប្លិ៍។ ចូលរួមជាមួយយើង!
ប្រភព: www.habr.com