ហេតុអ្វីបានជាវិស្វករមិនខ្វល់អំពីការត្រួតពិនិត្យកម្មវិធី?

រីករាយថ្ងៃសុក្រទាំងអស់គ្នា! មិត្តៗ ថ្ងៃនេះ យើងបន្តការបោះពុម្ពផ្សាយជាបន្តបន្ទាប់ ដែលឧទ្ទិសដល់វគ្គសិក្សា "ការអនុវត្ត និងឧបករណ៍ DevOps"ពីព្រោះថ្នាក់នៅក្នុងក្រុមថ្មីសម្រាប់វគ្គសិក្សានឹងចាប់ផ្តើមនៅចុងសប្តាហ៍ក្រោយ។ ដូច្នេះសូមចាប់ផ្តើម!

ការត្រួតពិនិត្យគឺ គ្រាន់តែ. នេះគឺជាការពិតដែលគេស្គាល់។ នាំ Nagios ដំណើរការ NRPE នៅលើប្រព័ន្ធពីចម្ងាយ កំណត់រចនាសម្ព័ន្ធ Nagios នៅលើច្រក NRPE TCP 5666 ហើយអ្នកមានការត្រួតពិនិត្យ។

វាងាយស្រួលណាស់វាមិនគួរឱ្យចាប់អារម្មណ៍ទេ។ ឥឡូវនេះអ្នកមានម៉ែត្រជាមូលដ្ឋានសម្រាប់ពេលវេលាស៊ីភីយូ ប្រព័ន្ធរងថាស RAM ដែលផ្គត់ផ្គង់តាមលំនាំដើមទៅ Nagios និង NRPE ។ ប៉ុន្តែនេះមិនមែនជា "ការត្រួតពិនិត្យ" តាមការពិតនោះទេ។ នេះ​គ្រាន់តែ​ជា​ការ​ចាប់ផ្តើម។

(ជាធម្មតាពួកគេដំឡើង PNP4Nagios, RRDtool និង Thruk ដំឡើងការជូនដំណឹងនៅក្នុង Slack ហើយទៅត្រង់ទៅ nagiosexchange ប៉ុន្តែសូមទុកវាចោលឥឡូវនេះ)។

ការត្រួតពិនិត្យល្អ។ ពិតជាស្មុគស្មាញណាស់ អ្នកពិតជាត្រូវដឹងពីផ្នែកខាងក្នុងនៃកម្មវិធីដែលអ្នកកំពុងត្រួតពិនិត្យ។

តើ​ការ​ត្រួត​ពិនិត្យ​ពិបាក​ទេ?

ម៉ាស៊ីនមេណាមួយ មិនថាលីនុច ឬវីនដូ តាមនិយមន័យនឹងបម្រើគោលបំណងមួយចំនួន។ Apache, Samba, Tomcat, ការផ្ទុកឯកសារ, LDAP - សេវាកម្មទាំងអស់នេះគឺមានច្រើនឬតិចតែមួយគត់ក្នុងការគោរពមួយ ឬច្រើន។ នីមួយៗមានមុខងារផ្ទាល់ខ្លួនលក្ខណៈរបស់វា។ មានវិធីផ្សេងគ្នាដើម្បីទទួលបានម៉ែត្រ KPIs (សូចនាករការអនុវត្តសំខាន់ៗ) ដែលគួរឱ្យចាប់អារម្មណ៍សម្រាប់អ្នកនៅពេលម៉ាស៊ីនមេកំពុងដំណើរការ។

អ្នកនិពន្ធរូបថត លូកាស៊ីសាសឺរ នៅលើ Unsplash

(ខ្ញុំចង់អោយផ្ទាំងគ្រប់គ្រងរបស់ខ្ញុំមានពណ៌ខៀវ neon - ដកដង្ហើមធំដោយសុបិន -... ហ៊ឺ...)

កម្មវិធីណាមួយដែលផ្តល់សេវាត្រូវតែមានយន្តការដើម្បីប្រមូលម៉ែត្រ។ Apache មានម៉ូឌុល mod-statusបង្ហាញទំព័រស្ថានភាពម៉ាស៊ីនមេ។ Nginx មាន - stub_status. Tomcat មានកម្មវិធី JMX ឬកម្មវិធីគេហទំព័រផ្ទាល់ខ្លួនដែលបង្ហាញរង្វាស់សំខាន់ៗ។ MySQL មានពាក្យបញ្ជា "បង្ហាញស្ថានភាពសកល" ។ល។
ដូច្នេះហេតុអ្វីបានជាអ្នកអភិវឌ្ឍន៍មិនបង្កើតយន្តការស្រដៀងគ្នាទៅក្នុងកម្មវិធីដែលពួកគេបង្កើត?

មានតែអ្នកអភិវឌ្ឍន៍ទេដែលធ្វើបែបនេះ?

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

អ្នកនិពន្ធរូបថត ទឹមហ្គូវ នៅលើ Unsplash

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

ការផ្លាស់ប្តូរការគិតទាក់ទងនឹងតម្រូវការសម្រាប់ម៉ែត្រត្រូវតែកើតឡើងមិនត្រឹមតែក្នុងចំណោមអ្នកអភិវឌ្ឍន៍ប៉ុណ្ណោះទេ ប៉ុន្តែក្នុងចំណោមវិស្វករប្រព័ន្ធផងដែរ។

សម្រាប់វិស្វករប្រព័ន្ធណាមួយដែលត្រូវការមិនត្រឹមតែឆ្លើយតបទៅនឹងព្រឹត្តិការណ៍សំខាន់ៗប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងធានាថាវាមិនកើតឡើងនោះ ការខ្វះខាតម៉ែត្រជាធម្មតាជាឧបសគ្គក្នុងការធ្វើដូច្នេះ។

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

នេះបំផ្លិចបំផ្លាញ

ចិត្តគំនិត devops ពិពណ៌នាអំពីការរួមបញ្ចូលគ្នារវាងការអភិវឌ្ឍន៍ (dev) និងការគិតបែបប្រតិបត្តិការ (ops) ។ ក្រុមហ៊ុនណាដែលអះអាងថា "ធ្វើ devops" ត្រូវ៖

1. និយាយអ្វីដែលពួកគេប្រហែលជាមិនធ្វើ (សំដៅលើ The Princess Bride meme - "ខ្ញុំមិនគិតថាវាមានន័យដូចអ្វីដែលអ្នកគិតថាវាមានន័យទេ!")
2. លើកទឹកចិត្តឱ្យមានអាកប្បកិរិយានៃការកែលម្អផលិតផលជាបន្តបន្ទាប់។

អ្នក​មិន​អាច​កែលម្អ​ផលិតផល​មួយ​បាន​ទេ ហើយ​ដឹង​ថា​វា​ត្រូវ​បាន​កែ​លម្អ​ប្រសិន​បើ​អ្នក​មិន​ដឹង​ថា​វា​ដំណើរការ​យ៉ាង​ណា​នា​ពេល​បច្ចុប្បន្ន។ អ្នក​មិន​អាច​ដឹង​ថា​តើ​ផលិតផល​ដំណើរការ​ដោយ​របៀប​ណា​ទេ ប្រសិន​បើ​អ្នក​មិន​យល់​ពី​របៀប​ដែល​សមាសធាតុ​របស់​វា​ដំណើរការ សេវាកម្ម​ដែល​វា​អាស្រ័យ​លើ ចំណុច​ឈឺ​ចាប់​ចម្បង​របស់​វា និង​បញ្ហា​ស្ទះ។
ប្រសិនបើអ្នកមិនមើលការស្ទះសក្តានុពលទេ អ្នកនឹងមិនអាចធ្វើតាមបច្ចេកទេស Five Whys នៅពេលសរសេរ Postmortem បានទេ។ អ្នក​នឹង​មិន​អាច​ដាក់​អ្វី​គ្រប់​យ៉ាង​នៅ​លើ​អេក្រង់​តែ​មួយ​ដើម្បី​មើល​ពី​របៀប​ដែល​ផលិតផល​ដំណើរការ ឬ​ដឹង​ថា​វា​មើល​ទៅ​ដូច​ជា "ធម្មតា និង​សប្បាយ​ចិត្ត" ទេ។

ប្តូរទៅឆ្វេង ឆ្វេង ខ្ញុំបាននិយាយថា LEEEE—

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

អ្នកនិពន្ធរូបថត អិនអេអេអេដោយអ្នកផលិត នៅលើ Unsplash

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

និយាយខ្លី

1. នាំសេះរបស់អ្នកទៅទឹក។ បង្ហាញអ្នកអភិវឌ្ឍន៍អំពីបញ្ហាដែលពួកគេអាចជៀសវាងសម្រាប់ខ្លួនគេ ជួយពួកគេកំណត់អត្តសញ្ញាណ KPIs និងម៉ែត្រត្រឹមត្រូវសម្រាប់កម្មវិធីរបស់ពួកគេ ដើម្បីកុំឱ្យមានការស្រែកយំពីម្ចាស់ផលិតផលដែលត្រូវបានស្រែកដោយ CTO ។ នាំពួកគេចូលទៅក្នុងពន្លឺដោយទន់ភ្លន់និងស្ងប់ស្ងាត់។ ប្រសិនបើវាមិនដំណើរការទេ សូមសំណូក គំរាមកំហែង និងច្រណែនពួកគេ ឬម្ចាស់ផលិតផល ដើម្បីអនុវត្តការទទួលបានម៉ែត្រទាំងនេះពីកម្មវិធីឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន ហើយបន្ទាប់មកគូរដ្យាក្រាម។ វានឹងពិបាកព្រោះវានឹងមិនត្រូវបានគេមើលឃើញថាជាអាទិភាពទេ ហើយផែនទីបង្ហាញផ្លូវផលិតផលនឹងមានគម្រោងបង្កើតប្រាក់ចំណូលជាច្រើនកំពុងរង់ចាំ។ ដូច្នេះហើយ អ្នកនឹងត្រូវការករណីអាជីវកម្ម ដើម្បីបង្ហាញអំពីភាពត្រឹមត្រូវនៃពេលវេលា និងការចំណាយដែលបានចំណាយក្នុងការអនុវត្តការត្រួតពិនិត្យទៅក្នុងផលិតផល។
2. ជួយវិស្វករប្រព័ន្ធឱ្យគេងលក់ស្រួល។ បង្ហាញពួកគេថាការប្រើបញ្ជីត្រួតពិនិត្យ "តោះចេញ" សម្រាប់ផលិតផលណាមួយដែលត្រូវបានចេញផ្សាយគឺជារឿងល្អ។ ហើយការធ្វើឱ្យប្រាកដថាកម្មវិធីទាំងអស់នៅក្នុងផលិតកម្មត្រូវបានគ្របដណ្ដប់ដោយរង្វាស់ នឹងជួយឱ្យអ្នកគេងលក់ស្រួលនៅពេលយប់ ដោយអនុញ្ញាតឱ្យអ្នកអភិវឌ្ឍន៍មើលឃើញថាមានអ្វីខុស និងកន្លែងណា។ ទោះជាយ៉ាងណាក៏ដោយ មធ្យោបាយត្រឹមត្រូវក្នុងការធ្វើឱ្យអ្នកអភិវឌ្ឍន៍ ម្ចាស់ផលិតផល ឬ CTO ខកចិត្តគឺត្រូវតស៊ូ និងប្រឆាំង។ ឥរិយាបថនេះនឹងប៉ះពាល់ដល់កាលបរិច្ឆេទចេញផ្សាយនៃផលិតផលណាមួយ ប្រសិនបើអ្នករង់ចាំរហូតដល់នាទីចុងក្រោយម្តងទៀត ដូច្នេះសូមប្តូរទៅខាងឆ្វេងម្តងទៀត ហើយយកបញ្ហាទាំងនេះទៅក្នុងគម្រោងគម្រោងរបស់អ្នកឱ្យបានឆាប់តាមដែលអាចធ្វើទៅបាន។ បើចាំបាច់ សូមធ្វើដំណើរទៅកាន់ការប្រជុំផលិតផល។ ពាក់ពុកមាត់ក្លែងក្លាយ ហើយមានអារម្មណ៍ ឬអ្វីមួយ វានឹងមិនដែលបរាជ័យឡើយ។ ទំនាក់ទំនងកង្វល់របស់អ្នក បង្ហាញអត្ថប្រយោជន៍ច្បាស់លាស់ និងផ្សាយដំណឹងល្អ។
3. ត្រូវប្រាកដថាទាំងការអភិវឌ្ឍន៍ (dev) និងប្រតិបត្តិការ (ops) យល់ពីអត្ថន័យ និងលទ្ធផលនៃរង្វាស់ផលិតផលដែលផ្លាស់ទីទៅក្នុងតំបន់ក្រហម។ កុំទុក Ops ជាអាណាព្យាបាលតែមួយគត់នៃសុខភាពផលិតផល សូមប្រាកដថាអ្នកអភិវឌ្ឍន៍ក៏ចូលរួមដែរ (#productsquads)។
4. កំណត់​ហេតុ​គឺ​ជា​រឿង​ដ៏​អស្ចារ្យ ប៉ុន្តែ​ក៏​ជា​ម៉ែត្រ​ដែរ។ ផ្សំពួកវា ហើយកុំឱ្យកំណត់ហេតុរបស់អ្នកក្លាយជាសំរាមនៅក្នុងដុំភ្លើងដ៏ធំដែលគ្មានប្រយោជន៍។ ពន្យល់ និងបង្ហាញអ្នកអភិវឌ្ឍន៍ថាហេតុអ្វីបានជាគ្មាននរណាម្នាក់នឹងយល់ពីកំណត់ហេតុរបស់ពួកគេ បង្ហាញពួកគេថាតើការមើលកំណត់ហេតុដែលគ្មានប្រយោជន៍នៅម៉ោង 3:15 ព្រឹក។

អ្នកនិពន្ធរូបថត លោក Marko Horvat នៅលើ Unsplash

អស់ហើយ។ សម្ភារៈថ្មីនឹងចេញនៅសប្តាហ៍ក្រោយ។ ប្រសិនបើអ្នកចង់ស្វែងយល់បន្ថែមអំពីវគ្គសិក្សានេះ យើងសូមអញ្ជើញអ្នកមកកាន់ ថ្ងៃបើកដែលនឹងប្រព្រឹត្តទៅនៅថ្ងៃច័ន្ទ។ ហើយឥឡូវនេះយើងកំពុងរង់ចាំជាប្រពៃណីសម្រាប់មតិយោបល់របស់អ្នក។

ប្រភព: www.habr.com