អ្នកអភិវឌ្ឍន៍មកពីភពព្រះអង្គារ Admins មកពី Venus

ភាពចៃដន្យគឺចៃដន្យ ហើយជាការពិតវាស្ថិតនៅលើភពផ្សេង...

ខ្ញុំចង់ចែករំលែករឿងជោគជ័យ និងបរាជ័យចំនួនបីអំពីរបៀបដែលអ្នកអភិវឌ្ឍន៍កម្មវិធីខាងក្រោយធ្វើការនៅក្នុងក្រុមជាមួយអ្នកគ្រប់គ្រង។

រឿងមួយ។
ស្ទូឌីយោគេហទំព័រ ចំនួនបុគ្គលិកអាចត្រូវបានរាប់ដោយដៃម្ខាង។ ថ្ងៃ​នេះ​អ្នក​ជា​អ្នក​រចនា​ប្លង់ ស្អែក​អ្នក​ជា​អ្នក​គាំទ្រ ថ្ងៃ​ស្អែក​អ្នក​ជា​អ្នក​គ្រប់គ្រង។ នៅលើដៃមួយអ្នកអាចទទួលបានបទពិសោធន៍ដ៏អស្ចារ្យ។ ម៉្យាង​វិញ​ទៀត​នៅ​ខ្វះ​សមត្ថភាព​គ្រប់​វិស័យ។ ខ្ញុំ​នៅ​ចាំ​ថ្ងៃ​ដំបូង​នៃ​ការ​ធ្វើ​ការ ខ្ញុំ​នៅ​តែ​បៃតង ថៅកែ​និយាយ​ថា “Open putty” ប៉ុន្តែ​ខ្ញុំ​មិន​ដឹង​ថា​វា​ជា​អ្វី​ទេ។ ការប្រាស្រ័យទាក់ទងជាមួយអ្នកគ្រប់គ្រងត្រូវបានដកចេញ ពីព្រោះ អ្នកគឺជាអ្នកគ្រប់គ្រងខ្លួនឯង។ ចូរយើងពិចារណាពីគុណសម្បត្តិ និងគុណវិបត្តិនៃស្ថានភាពនេះ។

+ អំណាចទាំងអស់គឺនៅក្នុងដៃរបស់អ្នក។
+ មិនចាំបាច់អង្វរអ្នកណាឱ្យចូលប្រើម៉ាស៊ីនមេទេ។
+ ពេលវេលាប្រតិកម្មរហ័សនៅគ្រប់ទិសដៅ។
+ ពង្រឹងជំនាញបានល្អ។
+ មានការយល់ដឹងពេញលេញអំពីស្ថាបត្យកម្មផលិតផល។

- ទំនួលខុសត្រូវខ្ពស់។
- ហានិភ័យនៃការបំបែកផលិតកម្ម។
- វាជាការលំបាកក្នុងការក្លាយជាអ្នកឯកទេសល្អក្នុងគ្រប់វិស័យ។

មិនចាប់អារម្មណ៍ តោះបន្តទៅមុខទៀត។

រឿងទីពីរ។
ក្រុមហ៊ុនធំ គម្រោងធំ។ មាននាយកដ្ឋានរដ្ឋបាលដែលមានបុគ្គលិក 5-7 នាក់ និងក្រុមអភិវឌ្ឍន៍ជាច្រើន។ នៅពេលអ្នកមកធ្វើការនៅក្នុងក្រុមហ៊ុនបែបនេះ រាល់ Admin តែងតែគិតថា អ្នកមិនបានមកធ្វើការលើផលិតផលនោះទេ ប៉ុន្តែដើម្បីបំបែកអ្វីមួយ។ ទាំង NDA ដែលបានចុះហត្ថលេខា ឬការជ្រើសរើសនៅឯការសម្ភាសបង្ហាញពីការមិនដូច្នេះទេ។ ទេ បុរសម្នាក់នេះមកទីនេះដោយដៃតូចកខ្វក់របស់គាត់ ដើម្បីបំផ្លាញផលិតកម្មថើបរបស់យើង។ ដូច្នេះជាមួយមនុស្សបែបនេះ អ្នកត្រូវការអប្បរមានៃទំនាក់ទំនង យ៉ាងហោចណាស់ អ្នកអាចបោះស្ទីគ័រឆ្លើយតបបាន។ កុំឆ្លើយសំណួរអំពីស្ថាបត្យកម្មគម្រោង។ មិនគួរផ្តល់ការចូលប្រើទេ រហូតដល់ប្រធានក្រុមសួរ។ ហើយ​ពេល​គាត់​សុំ គាត់​នឹង​ប្រគល់​វា​វិញ​ដោយ​មាន​សិទ្ធិ​តិច​ជាង​ការ​សុំ​ទៅ​ទៀត។ ការប្រាស្រ័យទាក់ទងស្ទើរតែទាំងអស់ជាមួយអ្នកគ្រប់គ្រងបែបនេះត្រូវបានស្រូបយកដោយប្រហោងខ្មៅរវាងនាយកដ្ឋានអភិវឌ្ឍន៍ និងនាយកដ្ឋានរដ្ឋបាល។ វាមិនអាចទៅរួចទេក្នុងការដោះស្រាយបញ្ហាភ្លាមៗ។ ប៉ុន្តែអ្នកមិនអាចមកដោយផ្ទាល់បានទេ - អ្នកគ្រប់គ្រងរវល់ពេក 24/7 ។ (តើអ្នកកំពុងធ្វើអ្វីគ្រប់ពេល?) លក្ខណៈនៃការសម្តែងមួយចំនួន៖

• ពេលវេលាដាក់ពង្រាយជាមធ្យមក្នុងផលិតកម្មគឺ 4-5 ម៉ោង។
• ពេលវេលាដាក់ពង្រាយអតិបរមាក្នុងផលិតកម្ម 9 ម៉ោង។
• សម្រាប់អ្នកអភិវឌ្ឍន៍ កម្មវិធីនៅក្នុងការផលិតគឺជាប្រអប់ខ្មៅមួយ ដូចទៅនឹងម៉ាស៊ីនមេផលិតខ្លួនឯងដែរ។ សរុបមានប៉ុន្មាននាក់?
• គុណភាពនៃការចេញផ្សាយទាប កំហុសញឹកញាប់
• អ្នកអភិវឌ្ឍន៍មិនចូលរួមក្នុងដំណើរការចេញផ្សាយទេ។

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

ច្បាប់ 1. អ្នកគ្រប់គ្រងគឺមើលមិនឃើញ។
ថ្ងៃចេញផ្សាយ អ្នកអភិវឌ្ឍន៍ និងអ្នកគ្រប់គ្រងមិនទាក់ទងគ្នាទេ។ Admin មិន​មាន​សំណួរ​អ្វី​ទេ។ ប៉ុន្តែអ្នកយល់ពីមូលហេតុនៅពេលក្រោយ។ Admin ជាមនុស្សមានគោលការណ៍ អត់មានអ្នកផ្ញើសារ មិនផ្តល់លេខទូរស័ព្ទរបស់គាត់ទៅនរណាម្នាក់ និងមិនមានប្រវត្តិរូបនៅលើបណ្តាញសង្គម។ មិន​មាន​សូម្បី​តែ​រូប​គាត់​នៅ​កន្លែង​ណា​ដែរ តើ​អ្នក​មើល​ទៅ​ដូច​ម្ដេច? យើងអង្គុយជាមួយអ្នកគ្រប់គ្រងដែលមានទំនួលខុសត្រូវប្រហែល 15 នាទីក្នុងភាពងឿងឆ្ងល់ ដោយព្យាយាមបង្កើតទំនាក់ទំនងជាមួយ Voyager 1 នេះ បន្ទាប់មកសារមួយលេចឡើងក្នុងអ៊ីមែលសាជីវកម្មដែលគាត់បានបញ្ចប់។ តើយើងនឹងឆ្លើយឆ្លងតាមសំបុត្រទេ? ហេតុអ្វីមិន? ងាយស្រួលមែនទេ? មិនអីទេ តោះត្រជាក់ចុះ។ ដំណើរការ​កំពុង​ដំណើរការ​ហើយ​មិន​មាន​ការ​វិល​ត្រឡប់​មក​វិញ​ទេ។ អានសារម្តងទៀត។ "ខ្ញុំ​បាន​បញ្ចប់"។ តើអ្នកបានបញ្ចប់អ្វីខ្លះ? កន្លែងណា? តើខ្ញុំគួររកមើលអ្នកនៅឯណា? នៅទីនេះអ្នកយល់ថាហេតុអ្វីបានជា 4 ម៉ោងសម្រាប់ការចេញផ្សាយគឺជារឿងធម្មតា។ យើងទទួលបានការភ្ញាក់ផ្អើលពីការអភិវឌ្ឍន៍ ប៉ុន្តែយើងបញ្ចប់ការចេញផ្សាយ។ លែង​មាន​បំណង​ចង់​ដោះ​លែង។

ច្បាប់ទី 2. មិនមែនជាកំណែនោះទេ។
ការចេញផ្សាយបន្ទាប់។ ដោយទទួលបានបទពិសោធន៍ យើងចាប់ផ្តើមបង្កើតបញ្ជីកម្មវិធី និងបណ្ណាល័យចាំបាច់សម្រាប់ម៉ាស៊ីនមេ សម្រាប់អ្នកគ្រប់គ្រង ដោយបង្ហាញពីកំណែសម្រាប់មួយចំនួន។ ដូចរាល់ដង យើងទទួលបានសញ្ញាវិទ្យុខ្សោយដែលអ្នកគ្រប់គ្រងបានបញ្ចប់អ្វីមួយនៅទីនោះ។ ការធ្វើតេស្តតំរែតំរង់ចាប់ផ្តើមដែលខ្លួនវាត្រូវចំណាយពេលប្រហែលមួយម៉ោង។ អ្វីៗហាក់ដូចជាដំណើរការ ប៉ុន្តែមានកំហុសសំខាន់មួយ។ មុខងារសំខាន់មិនដំណើរការទេ។ ប៉ុន្មានម៉ោងបន្ទាប់គឺកំពុងរាំជាមួយ tambourines ទស្សន៍ទាយនៅលើកាហ្វេ និងការពិនិត្យលម្អិតនៃកូដនីមួយៗ។ Admin ថាគាត់ធ្វើបានគ្រប់យ៉ាង។ កម្មវិធី​ដែល​សរសេរ​ដោយ​អ្នក​អភិវឌ្ឍន៍​ដែល​ច្រលំ​មិន​ដំណើរការ​ទេ ប៉ុន្តែ​ម៉ាស៊ីន​បម្រើ​ដំណើរការ។ មានសំណួរសម្រាប់គាត់ទេ? នៅចុងបញ្ចប់នៃមួយម៉ោង យើងទទួលបានអ្នកគ្រប់គ្រងឱ្យផ្ញើកំណែបណ្ណាល័យនៅលើម៉ាស៊ីនមេផលិតកម្មចូលទៅក្នុងការជជែក និងប៊ីងហ្គោ - វាមិនមែនជាអ្វីដែលយើងត្រូវការនោះទេ។ យើងស្នើឱ្យអ្នកគ្រប់គ្រងដំឡើងកំណែដែលត្រូវការ ប៉ុន្តែជាការឆ្លើយតប យើងទទួលបានថាគាត់មិនអាចធ្វើវាបានទេ ដោយសារអវត្តមាននៃកំណែនេះនៅក្នុងកម្មវិធីគ្រប់គ្រងកញ្ចប់ប្រព័ន្ធប្រតិបត្តិការ។ នៅទីនេះពីការសម្រាកនៃការចងចាំរបស់គាត់ អ្នកគ្រប់គ្រងចងចាំថាអ្នកគ្រប់គ្រងម្នាក់ទៀតបានដោះស្រាយបញ្ហានេះរួចហើយ ដោយគ្រាន់តែដំឡើងកំណែដែលត្រូវការដោយដៃ។ ប៉ុន្តែ​ទេ យើង​នឹង​មិន​ធ្វើ​បែប​នេះ​ទេ។ បទប្បញ្ញត្តិហាមឃាត់។ Karl យើង​បាន​អង្គុយ​នៅ​ទី​នេះ​អស់​ជា​ច្រើន​ម៉ោង តើ​មាន​ពេល​វេលា​កម្រិត​ណា?! យើងទទួលបានការភ្ញាក់ផ្អើលមួយទៀត ហើយបញ្ចប់ការចេញផ្សាយដោយរបៀបណា។

ច្បាប់ទី 3 ខ្លី
សំបុត្របន្ទាន់ មុខងារសំខាន់មិនដំណើរការសម្រាប់អ្នកប្រើប្រាស់ណាមួយនៅក្នុងផលិតកម្មទេ។ យើងចំណាយពេលពីរបីម៉ោងដើម្បីពិនិត្យ និងពិនិត្យ។ នៅក្នុងបរិយាកាសអភិវឌ្ឍន៍ អ្វីៗដំណើរការ។ មានការយល់ដឹងយ៉ាងច្បាស់ថា វាជាគំនិតល្អក្នុងការរកមើលកំណត់ហេតុ php-fpm ។ មិនមានប្រព័ន្ធកំណត់ហេតុដូចជា ELK ឬ Prometheus នៅលើគម្រោងនៅពេលនោះទេ។ យើងបើកសំបុត្រទៅនាយកដ្ឋានរដ្ឋបាលដើម្បីឱ្យពួកគេចូលប្រើកំណត់ហេតុ php-fpm នៅលើម៉ាស៊ីនមេ។ នៅទីនេះអ្នកត្រូវយល់ថាយើងកំពុងស្នើសុំការចូលប្រើសម្រាប់ហេតុផលមួយ តើអ្នកមិនចាំអំពីប្រហោងខ្មៅ ហើយអ្នកគ្រប់គ្រងរវល់ 24/7 ទេ? ប្រសិនបើអ្នកសុំឱ្យពួកគេមើលកំណត់ហេតុដោយខ្លួនឯង នោះគឺជាកិច្ចការដែលមានអាទិភាព "មិននៅក្នុងជីវិតនេះ"។ សំបុត្រត្រូវបានបង្កើតឡើង យើងបានទទួលការឆ្លើយតបភ្លាមៗពីប្រធាននាយកដ្ឋានរដ្ឋបាល៖ "អ្នកមិនគួរត្រូវការចូលទៅកាន់កំណត់ហេតុផលិតកម្មទេ សរសេរដោយគ្មានកំហុស"។ វាំងនន។

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

ការប្រែរូប។
ដោយបានស៊ូទ្រាំនឹងអ្វីៗទាំងអស់នេះអស់រយៈពេលជាយូរ រួមជាមួយនឹងក្រុម យើងបានចាប់ផ្តើមដឹកនាំក្នុងទិសដៅមួយដែលទទួលបានជោគជ័យជាងសម្រាប់យើង។ សរុបមក តើយើងបានជួបបញ្ហាអ្វីខ្លះ?

• កង្វះទំនាក់ទំនងគុណភាពរវាងអ្នកអភិវឌ្ឍន៍ និងផ្នែករដ្ឋបាល
• អ្នកគ្រប់គ្រង វាប្រែចេញ (!) មិនយល់ទាល់តែសោះពីរបៀបដែលកម្មវិធីត្រូវបានរៀបចំឡើង ភាពអាស្រ័យដែលវាមាន និងរបៀបដែលវាដំណើរការ។
• អ្នកអភិវឌ្ឍន៍មិនយល់ពីរបៀបដែលបរិយាកាសផលិតកម្មដំណើរការ ហើយជាលទ្ធផល មិនអាចឆ្លើយតបប្រកបដោយប្រសិទ្ធភាពចំពោះបញ្ហានោះទេ។
• ដំណើរការដាក់ពង្រាយចំណាយពេលយូរពេក។
• ការចេញផ្សាយមិនស្ថិតស្ថេរ។

តើយើងបានធ្វើអ្វី?
សម្រាប់ការចេញផ្សាយនីមួយៗ បញ្ជីនៃ Release Notes ត្រូវបានបង្កើតឡើង ដែលរួមបញ្ចូលនូវបញ្ជីការងារដែលត្រូវធ្វើនៅលើ Server សម្រាប់ការចេញផ្សាយបន្ទាប់ដើម្បីដំណើរការ។ បញ្ជីនេះមានផ្នែកជាច្រើន ការងារដែលគួរអនុវត្តដោយអ្នកគ្រប់គ្រង អ្នកទទួលខុសត្រូវចំពោះការចេញផ្សាយ និងអ្នកអភិវឌ្ឍន៍។ អ្នកអភិវឌ្ឍន៍បានទទួលការចូលប្រើមិនមែន root ទៅកាន់ម៉ាស៊ីនមេផលិតកម្មទាំងអស់ ដែលបង្កើនល្បឿននៃការអភិវឌ្ឍន៍ជាទូទៅ និងការដោះស្រាយបញ្ហាជាពិសេស។ អ្នកអភិវឌ្ឍន៍ក៏មានការយល់ដឹងអំពីរបៀបដែលផលិតកម្មដំណើរការ សេវាកម្មអ្វីដែលវាត្រូវបានបែងចែកទៅជាកន្លែង និងតម្លៃនៃការចម្លង។ បន្ទុកប្រយុទ្ធមួយចំនួនកាន់តែច្បាស់ ដែលពិតជាប៉ះពាល់ដល់គុណភាពនៃកូដ។ ការប្រាស្រ័យទាក់ទងក្នុងអំឡុងពេលដំណើរការចេញផ្សាយបានកើតឡើងនៅក្នុងការជជែករបស់អ្នកផ្ញើសារបន្ទាន់មួយ។ ទីមួយ យើងមានកំណត់ហេតុនៃសកម្មភាពទាំងអស់ ហើយទីពីរ ការប្រាស្រ័យទាក់ទងគ្នាបានកើតឡើងនៅក្នុងបរិយាកាសជិតស្និទ្ធ។ ការមានប្រវត្តិនៃសកម្មភាពបានអនុញ្ញាតឱ្យបុគ្គលិកថ្មីដោះស្រាយបញ្ហាបានច្រើនជាងម្តង។ វាជារឿងចម្លែក ប៉ុន្តែជារឿយៗវាជួយអ្នកគ្រប់គ្រងខ្លួនឯង។ ខ្ញុំនឹងមិននិយាយឱ្យប្រាកដទេ ប៉ុន្តែវាហាក់ដូចជាខ្ញុំថា អ្នកគ្រប់គ្រងបានចាប់ផ្តើមយល់កាន់តែច្រើនអំពីរបៀបដែលគម្រោងដំណើរការ និងរបៀបដែលវាត្រូវបានសរសេរ។ ពេលខ្លះយើងថែមទាំងចែករំលែកព័ត៌មានលម្អិតខ្លះៗដល់គ្នាទៅវិញទៅមក។ ពេលវេលាចេញផ្សាយជាមធ្យមត្រូវបានកាត់បន្ថយមកត្រឹមមួយម៉ោង។ ពេលខ្លះយើងធ្វើក្នុងរយៈពេល 30-40 នាទី។ ចំនួននៃកំហុសបានថយចុះយ៉ាងខ្លាំង ប្រសិនបើមិនមានដប់ដង។ ជាការពិតណាស់ កត្តាផ្សេងទៀតក៏បានជះឥទ្ធិពលដល់ការកាត់បន្ថយពេលវេលានៃការចេញផ្សាយផងដែរ ដូចជាការធ្វើតេស្តស្វ័យប្រវត្តិជាដើម។ បន្ទាប់ពីការចេញផ្សាយនីមួយៗ យើងចាប់ផ្តើមធ្វើការរំលឹកឡើងវិញ។ ដើម្បីឱ្យក្រុមទាំងមូលមានគំនិតអំពីអ្វីដែលថ្មី អ្វីដែលបានផ្លាស់ប្តូរ និងអ្វីដែលត្រូវបានដកចេញ។ ជាអកុសល Admin មិនតែងតែមករកពួកគេទេ មែនហើយ admin រវល់... ការពេញចិត្តការងាររបស់ខ្ញុំក្នុងនាមជាអ្នកអភិវឌ្ឍន៍មានការកើនឡើងដោយមិនសង្ស័យ។ នៅពេលដែលអ្នកអាចដោះស្រាយបញ្ហាស្ទើរតែទាំងអស់ដែលមាននៅក្នុងជំនាញរបស់អ្នកបានយ៉ាងឆាប់រហ័ស អ្នកមានអារម្មណ៍ថានៅលើកំពូល។ ក្រោយមក ខ្ញុំនឹងយល់ថា ដល់កម្រិតខ្លះ យើងបានណែនាំវប្បធម៌ devops មិនមែនទាំងស្រុងនោះទេ ប៉ុន្តែសូម្បីតែការចាប់ផ្តើមនៃការផ្លាស់ប្តូរក៏គួរអោយចាប់អារម្មណ៍ដែរ។

រឿងទីបី
ចាប់ផ្តើម។ អ្នកគ្រប់គ្រងម្នាក់ ផ្នែកអភិវឌ្ឍន៍តូច។ ពេលមកដល់ខ្ញុំជាសូន្យទាំងស្រុង ព្រោះ... ខ្ញុំ​មិន​អាច​ចូល​ទៅ​កន្លែង​ណា​បាន​ទេ លើក​លែង​តែ​ពី​សំបុត្រ។ យើង​សរសេរ​ទៅ​អ្នក​គ្រប់គ្រង ហើយ​សុំ​ចូល។ លើសពីនេះទៀត មានព័ត៌មានដែលថាគាត់ដឹងពីបុគ្គលិកថ្មី និងតម្រូវការក្នុងការចេញការចូល/ពាក្យសម្ងាត់។ ពួកគេផ្តល់ការចូលប្រើពីឃ្លាំង និង VPN ។ ហេតុអ្វី​បាន​ជា​អនុញ្ញាត​ឱ្យ​ចូល​ដំណើរការ​ទៅ​វិគី, teamcity, rundesk? រឿងដែលគ្មានប្រយោជន៍សម្រាប់មនុស្សម្នាក់ដែលត្រូវបានហៅឱ្យសរសេរផ្នែកខាងក្រោយទាំងមូល។ មានតែយូរៗទៅទេដែលយើងអាចចូលប្រើឧបករណ៍មួយចំនួន។ ជាការពិតណាស់ការមកដល់ត្រូវបានជួបជាមួយនឹងការមិនទុកចិត្ត។ ខ្ញុំកំពុងព្យាយាមស្វែងយល់បន្តិចម្តងៗអំពីរបៀបដែលហេដ្ឋារចនាសម្ព័ន្ធរបស់គម្រោងដំណើរការតាមរយៈការជជែក និងសំណួរនាំមុខ។ ជាទូទៅខ្ញុំមិនទទួលស្គាល់អ្វីទាំងអស់។ ការផលិតជាប្រអប់ខ្មៅដូចពីមុន។ ប៉ុន្តែលើសពីនោះ សូម្បីតែម៉ាស៊ីនមេដំណាក់កាលដែលប្រើសម្រាប់ការធ្វើតេស្តគឺជាប្រអប់ខ្មៅ។ យើងមិនអាចធ្វើអ្វីបានក្រៅពីពង្រាយសាខាពី Git នៅទីនោះ។ យើងក៏មិនអាចកំណត់រចនាសម្ព័ន្ធកម្មវិធីរបស់យើងដូចជាឯកសារ .env ដែរ។ ការចូលប្រើសម្រាប់ប្រតិបត្តិការបែបនេះមិនត្រូវបានផ្តល់ឱ្យទេ។ អ្នក​ត្រូវ​សុំ​ឱ្យ​មាន​ការ​ផ្លាស់​ប្តូរ​បន្ទាត់​ក្នុង​ការ​កំណត់​រចនាសម្ព័ន្ធ​កម្មវិធី​របស់​អ្នក​នៅ​លើ​ម៉ាស៊ីន​មេ​សាកល្បង។ (មានទ្រឹស្ដីមួយដែលថាវាមានសារៈសំខាន់ណាស់សម្រាប់អ្នកគ្រប់គ្រងក្នុងការមានអារម្មណ៍ថាខ្លួនឯងមានសារៈសំខាន់ចំពោះគម្រោងនេះ ប្រសិនបើពួកគេមិនត្រូវបានស្នើសុំឱ្យផ្លាស់ប្តូរបន្ទាត់នៅក្នុងការកំណត់ទេ នោះពួកគេនឹងមិនត្រូវការទេ)។ ដូចសព្វមួយដង តើវាមិនងាយស្រួលទេ? វាគួរឱ្យធុញទ្រាន់យ៉ាងឆាប់រហ័ស បន្ទាប់ពីការសន្ទនាដោយផ្ទាល់ជាមួយអ្នកគ្រប់គ្រង យើងបានរកឃើញថាអ្នកអភិវឌ្ឍន៍កើតមកដើម្បីសរសេរកូដមិនល្អ គឺជាបុគ្គលអសមត្ថភាពដោយធម្មជាតិ ហើយវាជាការប្រសើរជាងក្នុងការរក្សាពួកគេឱ្យឆ្ងាយពីផលិតកម្ម។ ប៉ុន្តែនៅទីនេះផងដែរពីម៉ាស៊ីនមេសាកល្បង, គ្រាន់តែក្នុងករណី។ ជម្លោះកំពុងកើនឡើងយ៉ាងឆាប់រហ័ស។ មិនមានទំនាក់ទំនងជាមួយ admin ទេ។ ស្ថានភាពកាន់តែធ្ងន់ធ្ងរទៅៗ ដោយសារគាត់នៅម្នាក់ឯង។ ខាងក្រោមនេះគឺជារូបភាពធម្មតា។ ចេញផ្សាយ។ មុខងារជាក់លាក់មិនដំណើរការទេ។ វាត្រូវចំណាយពេលយូរដើម្បីស្វែងយល់ថាតើមានអ្វីកើតឡើង គំនិតផ្សេងៗពីអ្នកអភិវឌ្ឍន៍ត្រូវបានបោះចូលទៅក្នុងការជជែក ប៉ុន្តែអ្នកគ្រប់គ្រងក្នុងស្ថានភាពបែបនេះជាធម្មតាសន្មត់ថាអ្នកអភិវឌ្ឍន៍នឹងត្រូវស្តីបន្ទោស។ បន្ទាប់មកគាត់សរសេរក្នុង chat ចាំខ្ញុំកែគាត់។ នៅ​ពេល​ដែល​ត្រូវ​បាន​ស្នើ​ឱ្យ​ទុក​រឿង​មួយ​នៅ​ពី​ក្រោយ​ដោយ​មាន​ព័ត៌មាន​អំពី​អ្វី​ដែល​ជា​បញ្ហា យើង​ទទួល​បាន​លេស​ពុល។ ចូលចិត្ត កុំបិទច្រមុះរបស់អ្នកនៅកន្លែងដែលវាមិនមែនជាកម្មសិទ្ធិ។ អ្នកអភិវឌ្ឍន៍ត្រូវតែសរសេរកូដ។ ស្ថានភាពនៅពេលដែលចលនារាងកាយជាច្រើននៅក្នុងគម្រោងមួយឆ្លងកាត់មនុស្សតែម្នាក់ ហើយមានតែគាត់ប៉ុណ្ណោះដែលអាចចូលដំណើរការប្រតិបត្តិការដែលមនុស្សគ្រប់គ្នាត្រូវការគឺពិតជាសោកសៅបំផុត។ មនុស្សបែបនេះគឺជាឧបសគ្គដ៏គួរឱ្យភ័យខ្លាច។ ប្រសិនបើគំនិត Devops ព្យាយាមកាត់បន្ថយពេលវេលាទៅទីផ្សារ នោះមនុស្សបែបនេះគឺជាសត្រូវដ៏អាក្រក់បំផុតនៃគំនិត Devops ។ ជាអកុសល វាំងននបិទនៅទីនេះ។

PS បន្ទាប់ពីនិយាយបន្តិចបន្តួចអំពីអ្នកអភិវឌ្ឍន៍ទល់នឹងអ្នកគ្រប់គ្រងក្នុងការជជែកជាមួយមនុស្ស ខ្ញុំបានជួបមនុស្សដែលចែករំលែកការឈឺចាប់របស់ខ្ញុំ។ ប៉ុន្តែ​ក៏​មាន​អ្នក​និយាយ​ថា​មិន​ដែល​ជួប​រឿង​បែប​នេះ​ដែរ។ នៅក្នុងសន្និសិទ devops មួយ ខ្ញុំបានសួរលោក Anton Isanin (Alfa Bank) ពីរបៀបដែលពួកគេដោះស្រាយបញ្ហានៃការស្ទះនៅក្នុងទម្រង់ជាអ្នកគ្រប់គ្រង ដែលគាត់បាននិយាយថា "យើងបានជំនួសពួកវាដោយប៊ូតុង" ។ និយាយ​អញ្ចឹង ផតខាស ដោយមានការចូលរួមរបស់គាត់។ ខ្ញុំ​ចង់​ជឿ​ថា​មាន​អ្នក​គ្រប់គ្រង​ល្អ​ច្រើន​ជាង​សត្រូវ។ បាទ រូបភាពនៅដើមដំបូងគឺជាការឆ្លើយឆ្លងពិតប្រាកដ។

ប្រភព៖ www.habr.com