វិធីសាស្រ្តប្រព័ន្ធចំពោះអថេរនៅក្នុង Ansible

ansible devops codestyle

ហេ! ឈ្មោះ​របស់ខ្ញុំ​គឺ Denis Kalyuzhny ខ្ញុំធ្វើការជាវិស្វករនៅក្នុងផ្នែកស្វ័យប្រវត្តិកម្មនៃដំណើរការអភិវឌ្ឍន៍។ ជារៀងរាល់ថ្ងៃ ការបង្កើតកម្មវិធីថ្មីត្រូវបានដាក់ឱ្យដំណើរការនៅលើម៉ាស៊ីនមេយុទ្ធនាការរាប់រយ។ ហើយនៅក្នុងអត្ថបទនេះខ្ញុំចែករំលែកបទពិសោធន៍របស់ខ្ញុំក្នុងការប្រើប្រាស់ Ansible សម្រាប់គោលបំណងទាំងនេះ។

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

• ដោយបានរកឃើញអថេរនៅក្នុងកូដ វាមិនអាចទៅរួចទេក្នុងការយល់ភ្លាមៗនូវអ្វីដែលវាទទួលខុសត្រូវ។
• មានតួនាទីជាច្រើន ហើយអថេរត្រូវភ្ជាប់ជាមួយតម្លៃមួយ ប៉ុន្តែវាមិនដំណើរការទេ។
• មានការពិបាកក្នុងការពន្យល់ដល់អ្នកដទៃពីរបៀបដែលតក្កវិជ្ជានៃអថេរនៅក្នុងសៀវភៅលេងរបស់អ្នកដំណើរការ

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

អថេរក្នុងតួនាទី

តួនាទីគឺជាវត្ថុដាច់ដោយឡែកនៃប្រព័ន្ធដាក់ពង្រាយ។ ដូចវត្ថុប្រព័ន្ធណាមួយដែរ វាត្រូវតែមានចំណុចប្រទាក់សម្រាប់អន្តរកម្មជាមួយប្រព័ន្ធដែលនៅសល់។ ចំណុចប្រទាក់បែបនេះគឺជាអថេរតួនាទី។

ចូរយើងយកឧទាហរណ៍តួនាទី apiដែលដំឡើងកម្មវិធី Java នៅលើម៉ាស៊ីនមេ។ តើវាអាចមានអថេរអ្វីខ្លះ?

តួនាទីអថេរអាចចែកចេញជា ២ ប្រភេទ ទៅតាមប្រភេទ៖

1. Свойства
    a) независимые от среды
    б) зависимые от среды
2. Связи
    a) слушатели 
    б) запросы внутри системы
    в) запросы в среду

លក្ខណៈសម្បត្តិអថេរ គឺជាអថេរដែលកំណត់ឥរិយាបថនៃតួនាទីមួយ។

អថេរសំណួរ - ទាំងនេះគឺជាអថេរដែលតម្លៃត្រូវបានប្រើដើម្បីកំណត់ធនធានខាងក្រៅទៅនឹងតួនាទី។

អ្នកស្តាប់អថេរ - ទាំងនេះគឺជាអថេរដែលតម្លៃត្រូវបានប្រើដើម្បីបង្កើតអថេរស្នើសុំ។

ម្យ៉ាងវិញទៀត 1a, 2a, 2b គឺជាអថេរដែលមិនអាស្រ័យលើបរិស្ថាន (ផ្នែករឹង ធនធានខាងក្រៅ។ល។) ហើយអាចត្រូវបានបំពេញដោយតម្លៃលំនាំដើមនៅក្នុងតួនាទីលំនាំដើម។ ទោះយ៉ាងណាក៏ដោយ វាមិនអាចទៅរួចទេក្នុងការបំពេញអថេរនៃប្រភេទ 1.b និង 2.c ជាមួយនឹងតម្លៃក្រៅពី 'ឧទាហរណ៍' ព្រោះវានឹងផ្លាស់ប្តូរពីឈរមួយទៅឈរអាស្រ័យលើបរិស្ថាន។

រចនាប័ទ្មកូដ

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

• ជៀសវាងការប្រើវចនានុក្រមសម្រាប់អថេរ។ Ansible មិនអនុញ្ញាតឱ្យអ្នកងាយស្រួលបដិសេធតម្លៃបុគ្គលនៅក្នុងវចនានុក្រមទេ។

  ឧទាហរណ៍នៃអថេរអាក្រក់៖

  myrole_user:
      login: admin
      password: admin

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

  myrole_user_login: admin
  myrole_user_password: admin

អថេរ​ក្នុង​សៀវភៅ​លេង​ដែល​ដាក់​ឱ្យ​ប្រើ

នៅពេលចងក្រងសៀវភៅលេងសម្រាប់ដាក់ពង្រាយ (តទៅនេះហៅថាសៀវភៅលេង) យើងប្រកាន់ខ្ជាប់នូវច្បាប់ដែលវាគួរតែត្រូវបានដាក់នៅក្នុងឃ្លាំងដាច់ដោយឡែកមួយ។ ដូចគ្នានឹងតួនាទី៖ នីមួយៗនៅក្នុងឃ្លាំង git របស់ខ្លួន។ នេះអនុញ្ញាតឱ្យអ្នកយល់ថាតួនាទី និងសៀវភៅលេងគឺជាវត្ថុឯករាជ្យផ្សេងគ្នានៃប្រព័ន្ធដាក់ពង្រាយ ហើយការផ្លាស់ប្តូរនៅក្នុងវត្ថុមួយមិនគួរប៉ះពាល់ដល់ប្រតិបត្តិការរបស់មួយផ្សេងទៀតនោះទេ។ នេះត្រូវបានសម្រេចដោយការផ្លាស់ប្តូរតម្លៃលំនាំដើមនៃអថេរ។

នៅពេលចងក្រងសៀវភៅលេង ដើម្បីសង្ខេប វាគឺអាចធ្វើទៅបានដើម្បីបដិសេធតម្លៃលំនាំដើមនៃអថេរតួនាទីនៅក្នុងពីរកន្លែង៖ នៅក្នុងអថេរ playbook និងនៅក្នុងអថេរសារពើភ័ណ្ឌ។

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   └── myapi.yml               # Файл переменных свойств группы myapi
└── inventories                 #
    └── prod                    # Каталог окружения prod
        ├── prod.ini            # Инвентори файл
        └── group_vars          # Каталог для переменных инвентори
            └── myapi           #
                ├── vars.yml    # Средозависимые переменные группы myapi
                └── vault.yml   # Секреты (всегда средозависимы) *

* - អថេរ និងតុដេក

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

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

នេះមានន័យថារួចហើយនៅដំណាក់កាលនេះ វាចាំបាច់ក្នុងការសម្រេចចិត្តថាតើអថេរអាស្រ័យលើបរិស្ថានឬអត់ ហើយដាក់វានៅកន្លែងសមរម្យ។

ឧទាហរណ៍ នៅក្នុងគម្រោងមួយ អថេរដែលទទួលខុសត្រូវចំពោះការបើក SSL គឺអាស្រ័យលើបរិស្ថានអស់រយៈពេលជាយូរ ដោយសារយើងមិនអាចបើក SSL សម្រាប់ហេតុផលដែលលើសពីការគ្រប់គ្រងរបស់យើងនៅទីតាំងមួយ។ បន្ទាប់​ពី​យើង​បាន​ដោះស្រាយ​បញ្ហា​នេះ វា​បាន​ក្លាយ​ទៅ​ជា​បរិស្ថាន​ឯករាជ្យ ហើយ​បាន​ផ្លាស់​ទៅ​អថេរ playbook ។

អថេរអចលនទ្រព្យសម្រាប់ក្រុម

ចូរពង្រីកគំរូរបស់យើងនៅក្នុងរូបភាពទី 1 ដោយបន្ថែមក្រុម 2 នៃម៉ាស៊ីនមេជាមួយនឹងកម្មវិធី Java ផ្សេងគ្នា ប៉ុន្តែជាមួយនឹងការកំណត់ផ្សេងគ្នា។

តោះ​ស្រមៃ​មើល​ថា​សៀវភៅ​លេង​នឹង​មាន​រូបរាង​យ៉ាង​ណា​ក្នុង​ករណី​នេះ៖

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

យើងមានក្រុមបីនៅក្នុងសៀវភៅលេង ដូច្នេះវាត្រូវបានណែនាំភ្លាមៗឱ្យបង្កើតចំនួនឯកសារក្រុមដូចគ្នានៅក្នុងអថេរសារពើភ័ណ្ឌ group_vars និងអថេរ playbook ។ ឯកសារក្រុមមួយនៅក្នុងករណីនេះគឺជាការពិពណ៌នានៃសមាសភាគមួយនៃកម្មវិធីខាងលើនៅក្នុងសៀវភៅលេង។ នៅពេលអ្នកបើកឯកសារក្រុមនៅក្នុងអថេរ playbook អ្នកឃើញភាពខុសគ្នាទាំងអស់ពីឥរិយាបថលំនាំដើមនៃតួនាទីដែលបានដំឡើងនៅលើក្រុម។ នៅក្នុងអថេរសារពើភ័ណ្ឌ៖ ភាពខុសគ្នានៅក្នុងឥរិយាបថក្រុមពីឈរមួយទៅកន្លែងឈរ។

រចនាប័ទ្មកូដ

• ព្យាយាមមិនប្រើអថេរ host_vars ទាល់តែសោះ ព្រោះពួកគេមិនពណ៌នាអំពីប្រព័ន្ធ ប៉ុន្តែមានតែករណីពិសេសមួយប៉ុណ្ណោះ ដែលនៅពេលអនាគតនឹងនាំឱ្យមានសំណួរ៖ "ហេតុអ្វីបានជាម៉ាស៊ីននេះខុសពីអ្នកផ្សេង?" ចម្លើយដែលមិនមែន តែងតែងាយស្រួលរក។

អថេរទំនាក់ទំនង

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

ដំបូងវាគឺជា គំនិតនេះ ប្រើសំណង់ដ៏អស្ចារ្យដូចជា៖
hostvars[groups['bbauth'][0]]['auth_bind_port']ប៉ុន្តែ​ពួកគេ​បាន​បដិសេធ​ភ្លាមៗ
ដោយសារតែវាមានគុណវិបត្តិ។ ទីមួយភាពច្របូកច្របល់។ ទីពីរ ការពឹងផ្អែកលើម៉ាស៊ីនជាក់លាក់មួយនៅក្នុងក្រុម។ ទីបី មុននឹងចាប់ផ្តើមដាក់ឱ្យប្រើប្រាស់ ចាំបាច់ត្រូវប្រមូលការពិតពីម៉ាស៊ីនទាំងអស់ ប្រសិនបើយើងមិនចង់ទទួលបានកំហុសនៃអថេរដែលមិនបានកំណត់។

ជាលទ្ធផល វាត្រូវបានសម្រេចចិត្តប្រើអថេរទំនាក់ទំនង។

អថេរទំនាក់ទំនង - ទាំងនេះគឺជាអថេរដែលជាកម្មសិទ្ធិរបស់ playbook ហើយត្រូវការដើម្បីភ្ជាប់វត្ថុប្រព័ន្ធ។

អថេរទំនាក់ទំនងត្រូវបានបញ្ចូលក្នុងអថេរប្រព័ន្ធទូទៅ group_vars/all/vars ហើយត្រូវបានបង្កើតឡើងដោយការដកអថេរអ្នកស្តាប់ទាំងអស់ចេញពីក្រុមនីមួយៗ ហើយបន្ថែមឈ្មោះក្រុមដែលអ្នកស្តាប់ត្រូវបានយកចេញទៅដើមអថេរ។

នេះធានាឱ្យមានឯកសណ្ឋាននិងមិនត្រួតស៊ីគ្នានៃឈ្មោះ។

តោះព្យាយាមចងអថេរពីឧទាហរណ៍ខាងលើ៖

ចូរស្រមៃថាយើងមានអថេរដែលអាស្រ័យលើគ្នាទៅវិញទៅមក៖

# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"

ចូរយើងដាក់វាចូលទៅក្នុងអថេរទូទៅ group_vars/all/vars អ្នកស្តាប់ទាំងអស់ ហើយបន្ថែមឈ្មោះក្រុមទៅចំណងជើង៖

# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"

# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"

# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"

# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"

ឥឡូវនេះដោយការផ្លាស់ប្តូរតម្លៃនៃឧបករណ៍ភ្ជាប់យើងនឹងប្រាកដថាសំណើនឹងទៅកន្លែងដដែលដែលច្រកស្ថិតនៅ។

រចនាប័ទ្មកូដ

• ដោយសារតួនាទី និងក្រុមគឺជាវត្ថុប្រព័ន្ធផ្សេងៗគ្នា ពួកគេត្រូវមានឈ្មោះផ្សេងគ្នា បន្ទាប់មកអថេរតំណនឹងបង្ហាញយ៉ាងត្រឹមត្រូវថាពួកគេជាកម្មសិទ្ធិរបស់ក្រុមជាក់លាក់នៃម៉ាស៊ីនមេ មិនមែនសម្រាប់តួនាទីនៅក្នុងប្រព័ន្ធនោះទេ។

ឯកសារដែលពឹងផ្អែកលើបរិស្ថាន

តួនាទីអាចប្រើឯកសារដែលខុសពីបរិស្ថានទៅបរិស្ថាន។

ឧទាហរណ៍នៃឯកសារបែបនេះគឺវិញ្ញាបនបត្រ SSL ។ រក្សាទុកពួកវាជាទម្រង់អត្ថបទ
នៅក្នុងអថេរគឺមិនងាយស្រួលទេ។ ប៉ុន្តែវាងាយស្រួលក្នុងការរក្សាទុកផ្លូវទៅកាន់ពួកវានៅខាងក្នុងអថេរមួយ។

ឧទាហរណ៍យើងប្រើអថេរ api_ssl_key_file: "/path/to/file".

ដោយសារវាច្បាស់ណាស់ថាវិញ្ញាបនបត្រសោនឹងផ្លាស់ប្តូរពីបរិស្ថានមួយទៅបរិស្ថាន នេះគឺជាអថេរអាស្រ័យលើបរិស្ថាន ដែលមានន័យថាវាគួរតែមានទីតាំងនៅក្នុងឯកសារ។
group_vars/myapi/vars សារពើភ័ណ្ឌនៃអថេរ និងមានតម្លៃ 'ឧទាហរណ៍' ។

មធ្យោបាយងាយស្រួលបំផុតក្នុងករណីនេះគឺត្រូវដាក់ឯកសារគន្លឹះនៅក្នុងឃ្លាំង playbook តាមបណ្តោយផ្លូវ
files/prod/certs/myapi.keyបន្ទាប់មកតម្លៃនៃអថេរនឹងមានៈ
api_ssl_key_file: "prod/certs/myapi.key". ភាពងាយស្រួលគឺស្ថិតនៅក្នុងការពិតដែលថាមនុស្សដែលទទួលខុសត្រូវក្នុងការដាក់ពង្រាយប្រព័ន្ធនៅកន្លែងជាក់លាក់មួយក៏មានកន្លែងផ្ទាល់ខ្លួនរបស់ពួកគេនៅក្នុងឃ្លាំងដើម្បីរក្សាទុកឯកសាររបស់ពួកគេ។ ក្នុងពេលជាមួយគ្នានេះ វានៅតែអាចបញ្ជាក់ផ្លូវដាច់ខាតទៅកាន់វិញ្ញាបនបត្រនៅលើម៉ាស៊ីនមេ ក្នុងករណីដែលវិញ្ញាបនបត្រត្រូវបានផ្គត់ផ្គង់ដោយប្រព័ន្ធមួយផ្សេងទៀត។

កន្លែងឈរជាច្រើននៅក្នុងបរិយាកាសមួយ។

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

វានឹងប្រើសារពើភ័ណ្ឌ group_vars ឡើងវិញ ហើយនឹងអាចកំណត់អថេរមួយចំនួនឡើងវិញដោយផ្ទាល់សម្រាប់ខ្លួនវាផងដែរ។

រចនាសម្ព័ន្ធថតចុងក្រោយសម្រាប់គម្រោងដាក់ពង្រាយ៖

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── files                       # Каталог для файлов деплоя
│   ├── prod                    # Католог для средозависимых файлов стенда prod
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Каталог для средозависимых файлов стенда test1
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   ├── myapi.yml               # Файл переменных свойств группы myapi
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Каталог окружения prod
    │   ├── group_vars          # Каталог для переменных инвентори
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Средозависимые переменные группы myapi
    │   │   │   └── vault.yml   # Секреты (всегда средозависимы)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Инвентори стенда prod
    └── test                    # Каталог окружения test
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Инвентори стенда test1 в среде test
        └── test2.ini           # Инвентори стенда test2 в среде test

សង្ខេប

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

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

អ្នក​គ្រប់គ្រង​ប្រព័ន្ធ​លែង​ត្រូវ​យល់​អំពី​កូដ​ដាក់​ពង្រាយ​ទៀត​ហើយ។ អ្វីទាំងអស់ដែលត្រូវបានទាមទារសម្រាប់ពួកគេសម្រាប់ការដាក់ពង្រាយដោយជោគជ័យគឺត្រូវបំពេញឯកសារនៃអថេរដែលពឹងផ្អែកលើបរិស្ថាន។

អក្សរសាស្រ្ត

1. ឯកសារ

អ្នកនិពន្ធ

Kalyuzhny Denis Alexandrovich

ប្រភព: www.habr.com