សន្និសីទសម្រាប់អ្នកគាំទ្រវិធីសាស្រ្ត DevOps

ជាការពិតណាស់យើងកំពុងនិយាយអំពី DevOpsConf. ប្រសិនបើអ្នកមិនចូលទៅក្នុងព័ត៌មានលម្អិតទេនោះ នៅថ្ងៃទី 30 ខែកញ្ញា និងថ្ងៃទី 1 ខែតុលា យើងនឹងរៀបចំសន្និសិទស្តីពីការរួមបញ្ចូលដំណើរការនៃការអភិវឌ្ឍន៍ ការធ្វើតេស្ត និងប្រតិបត្តិការ ហើយប្រសិនបើអ្នកចូលទៅក្នុងព័ត៌មានលម្អិត សូមនៅក្រោមឆ្មា។

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

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

នៅ​ពី​ក្រោយ​ឆាក

វាមានសារៈសំខាន់សម្រាប់យើងក្នុងការដឹងមិនត្រឹមតែអ្វីដែលក្រុមហ៊ុនផ្សេងគ្នាកំពុងធ្វើនៅក្នុងក្របខ័ណ្ឌនៃវិធីសាស្រ្ត DevOps ប៉ុណ្ណោះទេ ប៉ុន្តែក៏ត្រូវយល់ពីមូលហេតុដែលអ្វីៗទាំងអស់នេះត្រូវបានធ្វើផងដែរ។ ដូច្នេះហើយ យើងបានអញ្ជើញមិនត្រឹមតែអ្នកជំនាញឱ្យចូលរួមក្នុងគណៈកម្មាធិការកម្មវិធីប៉ុណ្ណោះទេ ប៉ុន្តែអ្នកឯកទេសដែលមើលឃើញសុន្ទរកថារបស់ DevOps មកពីមុខតំណែងផ្សេងៗគ្នា៖

• វិស្វករជាន់ខ្ពស់;
• អ្នកអភិវឌ្ឍន៍;
• ដឹកនាំក្រុម;
• CTO ។

ម៉្យាងវិញទៀត វាបង្កើតការលំបាក និងជម្លោះនៅពេលពិភាក្សាអំពីសំណើររបាយការណ៍។ ប្រសិនបើវិស្វករចាប់អារម្មណ៍ក្នុងការវិភាគឧបទ្ទវហេតុធំមួយ នោះវាសំខាន់ជាងសម្រាប់អ្នកអភិវឌ្ឍន៍ដើម្បីយល់ពីរបៀបបង្កើតកម្មវិធីដែលដំណើរការក្នុងពពក និងហេដ្ឋារចនាសម្ព័ន្ធ។ ប៉ុន្តែដោយការយល់ព្រម យើងបង្កើតកម្មវិធីដែលនឹងមានតម្លៃ និងគួរឱ្យចាប់អារម្មណ៍សម្រាប់មនុស្សគ្រប់គ្នា៖ ពីវិស្វកររហូតដល់ CTO ។

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

ផ្នែកសន្និសីទនឹងនៅដដែលដូចនៅក្នុង ពេលមុន.

• វេទិកាហេដ្ឋារចនាសម្ព័ន្ធ។
• ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ។
• ការចែកចាយបន្ត។
• មតិត្រឡប់។
• ស្ថាបត្យកម្មនៅក្នុង DevOps, DevOps សម្រាប់ CTO ។
• ការអនុវត្ត SRE ។
• ការបណ្តុះបណ្តាល និងការគ្រប់គ្រងចំណេះដឹង។
• សន្តិសុខ, DevSecOps ។
• ការផ្លាស់ប្តូរ DevOps ។

ហៅរកឯកសារ៖ តើរបាយការណ៍ប្រភេទណាដែលយើងកំពុងស្វែងរក

យើងបានបែងចែកទស្សនិកជនសក្តានុពលនៃសន្និសីទជាប្រាំក្រុម៖ វិស្វករ អ្នកអភិវឌ្ឍន៍ អ្នកឯកទេសសន្តិសុខ អ្នកដឹកនាំក្រុម និង CTO ។ ក្រុមនីមួយៗមានការលើកទឹកចិត្តរៀងៗខ្លួនដើម្បីមកសន្និសីទ។ ហើយប្រសិនបើអ្នកក្រឡេកមើល DevOps ពីមុខតំណែងទាំងនេះ អ្នកអាចយល់ពីរបៀបផ្តោតលើប្រធានបទរបស់អ្នក និងកន្លែងដែលត្រូវសង្កត់ធ្ងន់។

សម្រាប់វិស្វករ, ដែលកំពុងបង្កើតវេទិកាហេដ្ឋារចនាសម្ព័ន្ធ វាជារឿងសំខាន់ក្នុងការយល់ដឹងពីនិន្នាការដែលមានស្រាប់ ដើម្បីយល់ពីបច្ចេកវិទ្យាណាដែលទំនើបជាងគេ។ ពួកគេ​នឹង​ចាប់អារម្មណ៍​ក្នុង​ការ​សិក្សា​អំពី​បទពិសោធន៍​ក្នុង​ជីវិត​ពិត​ក្នុង​ការ​ប្រើប្រាស់​បច្ចេកវិទ្យា​ទាំងនេះ និង​ផ្លាស់ប្តូរ​យោបល់។ វិស្វករនឹងរីករាយក្នុងការស្តាប់របាយការណ៍ដែលវិភាគអំពីឧបទ្ទវហេតុពិបាកមួយចំនួន ហើយយើងនឹងព្យាយាមជ្រើសរើស និងកែលម្អរបាយការណ៍បែបនេះ។

សម្រាប់អ្នកអភិវឌ្ឍន៍ វាមានសារៈសំខាន់ណាស់ក្នុងការយល់ដឹងអំពីគំនិតបែបនេះ កម្មវិធីដើមនៃពពក. នោះ​គឺ​របៀប​បង្កើត​កម្មវិធី​ឲ្យ​វា​ដំណើរការ​ក្នុង​ពពក និង​ហេដ្ឋារចនាសម្ព័ន្ធ​ផ្សេងៗ។ អ្នកអភិវឌ្ឍន៍ត្រូវការទទួលមតិកែលម្អឥតឈប់ឈរពីកម្មវិធី។ នៅទីនេះយើងចង់ឮករណីអំពីរបៀបដែលក្រុមហ៊ុនបង្កើតដំណើរការនេះ របៀបតាមដានការអនុវត្តកម្មវិធី និងរបៀបដែលដំណើរការចែកចាយទាំងមូលដំណើរការ។

អ្នកឯកទេសសន្តិសុខតាមអ៊ីនធឺណិត វាមានសារៈសំខាន់ណាស់ក្នុងការយល់ដឹងពីរបៀបរៀបចំដំណើរការសុវត្ថិភាព ដើម្បីកុំឱ្យវាជាប់គាំងដល់ការអភិវឌ្ឍន៍ និងការផ្លាស់ប្តូរដំណើរការនៅក្នុងក្រុមហ៊ុន។ ប្រធានបទអំពីតម្រូវការដែល DevOps ដាក់លើអ្នកឯកទេសបែបនេះក៏នឹងគួរឱ្យចាប់អារម្មណ៍ផងដែរ។

អ្នកដឹកនាំក្រុមចង់ដឹងរបៀបដែលដំណើរការចែកចាយបន្តដំណើរការនៅក្នុងក្រុមហ៊ុនផ្សេងទៀត។ តើ​ក្រុមហ៊ុន​យក​ផ្លូវ​ណា​ខ្លះ​ដើម្បី​សម្រេច​បាន​វា តើ​ពួកគេ​បាន​បង្កើត​ដំណើរការ​អភិវឌ្ឍន៍ និង​ការធានា​គុណភាព​ដោយ​របៀបណា​នៅក្នុង DevOps។ អ្នកដឹកនាំក្រុមក៏ចាប់អារម្មណ៍លើ Cloud ដើមផងដែរ។ ហើយក៏មានសំណួរអំពីអន្តរកម្មក្នុងក្រុម និងរវាងក្រុមអភិវឌ្ឍន៍ និងវិស្វកម្មផងដែរ។

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

បើ​មាន​រឿង​ចង់​និយាយ​ពី​រឿង​ទាំង​នេះ កុំ​នៅ​ស្ងៀម ដាក់របាយការណ៍របស់អ្នក។. ថ្ងៃផុតកំណត់សម្រាប់ Call for Papers គឺថ្ងៃទី 20 ខែសីហា។ កាលណាអ្នកចុះឈ្មោះមុន ពេលវេលាកាន់តែច្រើន អ្នកនឹងត្រូវបញ្ចប់របាយការណ៍របស់អ្នក ហើយរៀបចំសម្រាប់ការធ្វើបទបង្ហាញរបស់អ្នក។ ដូច្នេះកុំពន្យាពេល។

ជាការប្រសើរណាស់, ប្រសិនបើអ្នកមិនមានតម្រូវការក្នុងការនិយាយជាសាធារណៈ, គ្រាន់តែ ទិញសំបុត្រមួយ។ ហើយមកនៅថ្ងៃទី 30 ខែកញ្ញា និងថ្ងៃទី 1 ខែតុលា ដើម្បីទំនាក់ទំនងជាមួយសហសេវិក។ យើងសន្យាថាវានឹងគួរឱ្យចាប់អារម្មណ៍ និងបំផុសគំនិត។

របៀបដែលយើងឃើញ DevOps

ដើម្បីយល់ពីអ្វីដែលយើងចង់មានន័យដោយ DevOps ខ្ញុំសូមណែនាំឱ្យអាន (ឬអានឡើងវិញ) របាយការណ៍របស់ខ្ញុំ "តើ DevOps ជាអ្វី?" ដោយដើរឆ្លងកាត់រលកនៃទីផ្សារ ខ្ញុំបានសង្កេតមើលពីរបៀបដែលគំនិតរបស់ DevOps កំពុងផ្លាស់ប្តូរនៅក្នុងក្រុមហ៊ុនដែលមានទំហំខុសៗគ្នា៖ ពីការចាប់ផ្តើមអាជីវកម្មខ្នាតតូចរហូតដល់ក្រុមហ៊ុនពហុជាតិ។ របាយការណ៍នេះត្រូវបានបង្កើតឡើងនៅលើសំណួរជាបន្តបន្ទាប់ ដោយឆ្លើយពួកគេ អ្នកអាចយល់ថាតើក្រុមហ៊ុនរបស់អ្នកកំពុងឆ្ពោះទៅរក DevOps ឬថាតើមានបញ្ហានៅកន្លែងណាមួយឬអត់។

DevOps គឺជាប្រព័ន្ធស្មុគស្មាញ វាត្រូវតែរួមបញ្ចូលៈ

• ផលិតផលឌីជីថល។
• ម៉ូឌុលអាជីវកម្មដែលអភិវឌ្ឍផលិតផលឌីជីថលនេះ។
• ក្រុមផលិតផលដែលសរសេរកូដ។
• ការអនុវត្តការចែកចាយបន្ត។
• វេទិកាជាសេវាកម្ម។
• ហេដ្ឋារចនាសម្ព័ន្ធជាសេវាកម្ម។
• ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ។
• ការអនុវត្តដាច់ដោយឡែកសម្រាប់ការរក្សាភាពជឿជាក់បានបង្កើតឡើងនៅក្នុង DevOps ។
• ការអនុវត្តមតិកែលម្អដែលពិពណ៌នាអំពីវាទាំងអស់។

នៅចុងបញ្ចប់នៃរបាយការណ៍មានដ្យាក្រាមដែលផ្តល់គំនិតអំពីប្រព័ន្ធ DevOps នៅក្នុងក្រុមហ៊ុន។ វា​នឹង​អនុញ្ញាត​ឱ្យ​អ្នក​មើល​ឃើញ​ថា​ដំណើរការ​មួយ​ណា​ក្នុង​ក្រុមហ៊ុន​របស់​អ្នក​ត្រូវ​បាន​សម្រួល​រួច​ហើយ និង​ដែល​មិន​ទាន់​ត្រូវ​បាន​បង្កើត​ឡើង។

អ្នកអាចមើលវីដេអូនៃរបាយការណ៍ នៅទីនេះ.

ហើយឥឡូវនេះនឹងមានប្រាក់រង្វាន់៖ វីដេអូជាច្រើនពី RIT ++ 2019 ដែលប៉ះលើបញ្ហាទូទៅបំផុតនៃការផ្លាស់ប្តូរ DevOps ។

ហេដ្ឋារចនាសម្ព័ន្ធក្រុមហ៊ុនជាផលិតផល

Artyom Naumenko ដឹកនាំក្រុម DevOps នៅ Skyeng និងយកចិត្តទុកដាក់លើការអភិវឌ្ឍន៍ហេដ្ឋារចនាសម្ព័ន្ធរបស់ក្រុមហ៊ុនគាត់។ គាត់បានប្រាប់ពីរបៀបដែលហេដ្ឋារចនាសម្ព័ន្ធប៉ះពាល់ដល់ដំណើរការអាជីវកម្មនៅ SkyEng៖ របៀបគណនា ROI សម្រាប់វា តើម៉ែត្រអ្វីដែលគួរត្រូវបានជ្រើសរើសសម្រាប់ការគណនា និងរបៀបធ្វើការដើម្បីកែលម្អពួកគេ។

នៅលើផ្លូវទៅកាន់សេវាមីក្រូ

ក្រុមហ៊ុន Nixys ផ្តល់ការគាំទ្រសម្រាប់គម្រោងបណ្ដាញមមាញឹក និងប្រព័ន្ធចែកចាយ។ នាយកបច្ចេកទេសរបស់ខ្លួន Boris Ershov បានប្រាប់ពីរបៀបបកប្រែផលិតផលសូហ្វវែរ ការអភិវឌ្ឍន៍ដែលបានចាប់ផ្តើមកាលពី 5 ឆ្នាំមុន (ឬច្រើនជាងនេះ) ទៅលើវេទិកាទំនើប។

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

អ្នកគ្រប់គ្រងគម្រោងបែបនេះប្រឈមមុខនឹងតម្រូវការក្នុងការផ្លាស់ប្តូរដំណើរការបច្ចេកវិទ្យាទាំងអស់។ នៅក្នុងរបាយការណ៍របស់គាត់ Boris បាននិយាយថា:

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

ស្វ័យប្រវត្តិកម្មនៃការចេញផ្សាយ ឬរបៀបចែកចាយយ៉ាងឆាប់រហ័ស និងគ្មានការឈឺចាប់

Alexander Korotkov គឺជាអ្នកអភិវឌ្ឍន៍ឈានមុខគេនៃប្រព័ន្ធ CI/CD នៅ CIAN ។ គាត់បាននិយាយអំពីឧបករណ៍ស្វ័យប្រវត្តិកម្មដែលធ្វើឱ្យវាអាចធ្វើឱ្យប្រសើរឡើងនូវគុណភាពនិងកាត់បន្ថយពេលវេលាសម្រាប់ការបញ្ជូនលេខកូដទៅផលិតកម្មចំនួន 5 ដង។ ប៉ុន្តែលទ្ធផលបែបនេះមិនអាចសម្រេចបានដោយប្រើស្វ័យប្រវត្តិកម្មតែម្នាក់ឯងទេ ដូច្នេះអាឡិចសាន់ឌឺក៏បានយកចិត្តទុកដាក់ចំពោះការផ្លាស់ប្តូរក្នុងដំណើរការអភិវឌ្ឍន៍។

តើគ្រោះថ្នាក់ជួយអ្នករៀនយ៉ាងដូចម្តេច?

Alexey Kirpichnikov បាននិងកំពុងអនុវត្ត DevOps និងហេដ្ឋារចនាសម្ព័ន្ធនៅ SKB Kontur អស់រយៈពេល 5 ឆ្នាំ។ ក្នុងរយៈពេលបីឆ្នាំ ប្រហែល 1000 fakaps នៃកម្រិតខុសគ្នានៃវីរភាពបានកើតឡើងនៅក្នុងក្រុមហ៊ុនរបស់គាត់។ ជាឧទាហរណ៍ ក្នុងចំណោមពួកគេ 36% ត្រូវបានបង្កឡើងដោយការចេញផ្សាយការចេញផ្សាយដែលមានគុណភាពទាបទៅក្នុងផលិតកម្ម ហើយ 14% ត្រូវបានបង្កឡើងដោយការងារថែទាំផ្នែករឹងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ។

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

នៅក្នុងសុន្ទរកថារបស់គាត់ Alexey បានចែករំលែកពីរបៀបសរសេរ postmortem ដ៏មានប្រយោជន៍ និងរបៀបអនុវត្តការអនុវត្តរបាយការណ៍បែបនេះនៅក្នុងក្រុមហ៊ុនធំមួយ។ បើ​អ្នក​ចូល​ចិត្ត​រឿង​ដែល​មាន​នរណា​ម្នាក់​លួច​មើល​វីដេអូ​នៃ​ការ​សម្តែង។

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

តើរបាយការណ៍អ្វីខ្លះដែលយើងបានទទួលយកទៅក្នុងកម្មវិធីរួចហើយ?

សប្តាហ៍នេះ គណៈកម្មាធិការកម្មវិធីបានអនុម័តរបាយការណ៍ចំនួន ៤៖ ស្តីពីសន្តិសុខ ហេដ្ឋារចនាសម្ព័ន្ធ និងការអនុវត្ត SRE ។

ប្រហែលជាប្រធានបទដ៏ឈឺចាប់បំផុតនៃការផ្លាស់ប្តូរ DevOps៖ របៀបធ្វើឱ្យប្រាកដថាបុរសមកពីផ្នែកសន្តិសុខព័ត៌មានមិនបំផ្លាញទំនាក់ទំនងដែលបានបង្កើតរួចហើយរវាងការអភិវឌ្ឍន៍ ប្រតិបត្តិការ និងការគ្រប់គ្រង។ ក្រុមហ៊ុនខ្លះគ្រប់គ្រងដោយគ្មាននាយកដ្ឋានសន្តិសុខព័ត៌មាន. តើធ្វើដូចម្តេចដើម្បីធានាសុវត្ថិភាពព័ត៌មានក្នុងករណីនេះ? អំពី​វា នឹងប្រាប់ Mona Arkhipova ពី sudo.su. ពីរបាយការណ៍របស់នាងយើងរៀន៖

• អ្វីដែលត្រូវការពារ និងពីអ្នកណា។
• តើអ្វីជាដំណើរការសុវត្ថិភាពជាប្រចាំ។
• របៀបដែល IT និងដំណើរការសុវត្ថិភាពព័ត៌មានប្រសព្វគ្នា;
• តើ CIS CSC ជាអ្វី និងរបៀបអនុវត្តវា;
• របៀប និងដោយសូចនាករអ្វីខ្លះ ដើម្បីធ្វើការត្រួតពិនិត្យសុវត្ថិភាពព័ត៌មានជាប្រចាំ។

របាយការណ៍បន្ទាប់ទាក់ទងនឹងការអភិវឌ្ឍន៍ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ។ កាត់បន្ថយចំនួននៃទម្លាប់ធ្វើដោយដៃ ហើយមិនបង្វែរគម្រោងទាំងមូលទៅជាភាពវឹកវរ តើនេះអាចទៅរួចទេ? ចំពោះសំណួរនេះ។ នឹងឆ្លើយ Maxim Kostrikin មកពី Ixtens. ក្រុមហ៊ុនរបស់គាត់ប្រើ Terraform សម្រាប់ធ្វើការជាមួយហេដ្ឋារចនាសម្ព័ន្ធ AWS ។ ឧបករណ៍គឺងាយស្រួល ប៉ុន្តែសំណួរគឺរបៀបជៀសវាងការបង្កើតប្លុកដ៏ធំនៃកូដនៅពេលប្រើវា។ ការថែរក្សាកេរដំណែលបែបនេះនឹងមានតម្លៃថ្លៃជាងជារៀងរាល់ឆ្នាំ។ 

Maxim នឹងបង្ហាញពីរបៀបដែលគំរូនៃការដាក់កូដដំណើរការ សំដៅលើការសម្រួលដល់ស្វ័យប្រវត្តិកម្ម និងការអភិវឌ្ឍន៍។

មួយទៀត របាយការណ៍ យើងនឹងឮអំពីហេដ្ឋារចនាសម្ព័ន្ធពី Vladimir Ryabov មកពី Playkey. នៅទីនេះយើងនឹងនិយាយអំពីវេទិកាហេដ្ឋារចនាសម្ព័ន្ធ ហើយយើងនឹងសិក្សា៖

• របៀបស្វែងយល់ថាតើទំហំផ្ទុកត្រូវបានប្រើប្រាស់យ៉ាងមានប្រសិទ្ធភាពឬអត់
• តើអ្នកប្រើប្រាស់ប៉ុន្មានរយនាក់អាចទទួលបានមាតិកា 10 TB ប្រសិនបើទំហំផ្ទុកត្រឹមតែ 20 TB ត្រូវបានប្រើប្រាស់។
• របៀបបង្ហាប់ទិន្នន័យ 5 ដង និងផ្តល់វាដល់អ្នកប្រើប្រាស់ក្នុងពេលវេលាជាក់ស្តែង។
• របៀបធ្វើសមកាលកម្មទិន្នន័យក្នុងពេលហោះហើររវាងមជ្ឈមណ្ឌលទិន្នន័យជាច្រើន;
• របៀប​លុប​បំបាត់​ឥទ្ធិពល​របស់​អ្នក​ប្រើ​លើ​គ្នា​ទៅ​វិញ​ទៅ​មក ពេល​ប្រើ​ម៉ាស៊ីន​និម្មិត​មួយ​តាម​លំដាប់​លំដោយ។

អាថ៌កំបាំងនៃវេទមន្តនេះគឺបច្ចេកវិទ្យា ZFS សម្រាប់ FreeBSD និងសមស្រស់របស់វា។ ZFS នៅលើលីនុច. វ្ល៉ាឌីមៀនឹងចែករំលែកករណីពី Playkey ។

Matvey Kukuy មកពី Amixr.IO ត្រៀមខ្លួនជាស្រេចជាមួយនឹងឧទាហរណ៍ពីជីវិត ប្រាប់, តើ​មាន​រឿង​អ្វី​កើតឡើង SRE និងរបៀបដែលវាជួយបង្កើតប្រព័ន្ធដែលអាចទុកចិត្តបាន។ Amixr.IO ឆ្លងកាត់ឧប្បត្តិហេតុរបស់អតិថិជនតាមរយៈផ្នែកខាងក្រោយរបស់វា ក្រុមការងារដែលបំពេញកាតព្វកិច្ចរាប់សិបនាក់នៅជុំវិញពិភពលោកបានដោះស្រាយរួចហើយជាមួយនឹងករណីចំនួន 150 ។ នៅក្នុងសន្និសិទ Matvey នឹងចែករំលែកស្ថិតិ និងការយល់ដឹងដែលក្រុមហ៊ុនរបស់គាត់បានប្រមូលផ្តុំដោយការដោះស្រាយបញ្ហាអតិថិជន និងការវិភាគការបរាជ័យ។

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

ប្រភព: www.habr.com