CTO ගේ නිපුණතාවය පරීක්ෂා කරනු ලබන්නේ ඔහු මෙම භූමිකාව ඉටු කරන දෙවන වරට පමණක් බව දන්නා කරුණකි. මක්නිසාද යත් සමාගමක වසර කිහිපයක් වැඩ කිරීම, එය සමඟ පරිණාමය වීම සහ එකම සංස්කෘතික සන්දර්භය තුළ සිටීම, ක්‍රමයෙන් වැඩි වගකීමක් ලැබීම එක් දෙයක් වන බැවිනි. තවද, ලෙගසි ගමන් මලු සහ ගැටළු ගොන්නක් පිළිවෙළකට පාපිස්ස යට ගසාගෙන යන සමාගමක තාක්ෂණික අධ්‍යක්ෂ තනතුරට කෙලින්ම පැමිණීම තවත් එකකි.

මේ අර්ථයෙන්, ඔහු බෙදාගත් ලියොන් ෆයර්ගේ අත්දැකීම DevOpsConf, හරියටම අද්විතීය නොවේ, නමුත් ඔහුගේ අත්දැකීම් සහ වසර 20 ක කාලය තුළ ඔහු උත්සාහ කිරීමට සමත් වූ විවිධ භූමිකාවන් ගණනින් ගුණ කිරීම, එය ඉතා ප්රයෝජනවත් වේ. කප්පාදුවට පහළින් ඇත්තේ දින 90කට වැඩි සිදුවීම්වල කාලානුක්‍රමය සහ ඒවා වෙනත් කෙනෙකුට සිදු වූ විට සිනාසීමට විනෝදජනක, නමුත් පුද්ගලිකව මුහුණ දීමට එතරම් විනෝදජනක නොවන කථා රාශියක් ය.

ලියොන් රුසියානු භාෂාවෙන් ඉතා වර්ණවත් ලෙස කථා කරයි, එබැවින් ඔබට විනාඩි 35-40 ක් තිබේ නම්, මම වීඩියෝව නැරඹීමට නිර්දේශ කරමි. පහතින් කාලය ඉතිරි කර ගැනීමට පෙළ අනුවාදය.

වාර්තාවේ පළමු අනුවාදය ප්‍රයෝජනවත් නිර්දේශ අඩංගු පුද්ගලයන් සහ ක්‍රියාවලීන් සමඟ වැඩ කිරීමේ හොඳින් ව්‍යුහගත විස්තරයකි. නමුත් මඟදී මුහුණ දුන් සියලු විස්මයන් ඇය ප්‍රකාශ කළේ නැත. ඒ නිසා මම ආකෘතිය වෙනස් කර නව ආයතනයේ කොස් ඇටයක් මෙන් මා ඉදිරියේ මතු වූ ගැටලු සහ ඒවා විසඳීමේ ක්‍රම කාලානුක්‍රමයට ඉදිරිපත් කළෙමි.

මාසයකට පෙර

ගොඩක් හොඳ කතා වගේම මේකත් පටන් ගත්තෙ මත්පැන් වලින්. අපි මිතුරන් සමඟ බාර් එකක වාඩි වී සිටි අතර, තොරතුරු තාක්ෂණ විශේෂඥයින් අතර අපේක්ෂා කළ පරිදි, සෑම කෙනෙකුම ඔවුන්ගේ ගැටළු ගැන හඬා වැටෙමින් සිටියහ. ඔවුන්ගෙන් එක් අයෙක් රැකියාව වෙනස් කර ඇති අතර ඔහුගේ තාක්ෂණය සහ මිනිසුන් සමඟ සහ කණ්ඩායම සමඟ ඔහුගේ ගැටළු ගැන කතා කරමින් සිටියේය. මම ඇහුම්කන් දෙන තරමට, ඔහු මාව කුලියට ගත යුතු බව මට වැටහුණි, මන්ද මේවා මම පසුගිය වසර 15 තුළ විසඳා ඇති ගැටලු ය. මම ඔහුට එහෙම කිව්වා, ඊළඟ දවසේ අපි වැඩ කරන පරිසරයකදී මුණගැසුණා. සමාගම හැඳින්වූයේ ඉගැන්වීමේ උපාය මාර්ග යනුවෙනි.

ඉගැන්වීමේ උපාය මාර්ග උපතේ සිට අවුරුදු තුන දක්වා ඉතා කුඩා දරුවන් සඳහා විෂය මාලාවේ වෙළඳපල ප්‍රමුඛයා වේ. සාම්ප්රදායික "කඩදාසි" සමාගම දැනටමත් වසර 40 ක් පැරණි වන අතර, වේදිකාවේ ඩිජිටල් SaaS අනුවාදය වසර 10 ක් පැරණි, සාපේක්ෂව මෑතදී, සමාගම් ප්රමිතීන්ට ඩිජිටල් තාක්ෂණය අනුවර්තනය කිරීමේ ක්රියාවලිය ආරම්භ විය. "නව" අනුවාදය 2017 දී දියත් කරන ලද අතර එය පැරණි එක හා සමාන විය, එය වඩාත් නරක ලෙස වැඩ කළේය.

වඩාත්ම සිත්ගන්නා කරුණ නම්, මෙම සමාගමේ ගමනාගමනය ඉතා පුරෝකථනය කළ හැකි වීමයි - දිනෙන් දින, වසරින් වසර, කොපමණ පුද්ගලයින් පැමිණෙන්නේද සහ කවදාද යන්න ඔබට ඉතා පැහැදිලිව පුරෝකථනය කළ හැකිය. නිදසුනක් වශයෙන්, ප.ව. 13 ත් 15 ත් අතර ළදරු පාසල්වල සිටින සියලුම දරුවන් නින්දට යන අතර ගුරුවරුන් තොරතුරු ඇතුළත් කිරීමට පටන් ගනී. සති අන්තයේ හැර සෑම දිනකම මෙය සිදු වේ, මන්ද කිසිවෙකු සති අන්තයේ වැඩ නොකරන බැවිනි.

මඳක් ඉදිරියෙන් බලන විට, මම මගේ වැඩ ආරම්භ කළේ ඉහළම වාර්ෂික ගමනාගමන කාලය තුළ බව සටහන් කරමි, එය විවිධ හේතු නිසා සිත්ගන්නා සුළුය.

2 වසරේ සිට ColdFusion & SQL Server: වේදිකාවට වසර 2008ක් පමණක් පැරණි බව පෙනේ. ColdFusion, ඔබ නොදන්නේ නම් සහ බොහෝ විට ඔබ නොදන්නේ නම්, 90 දශකයේ මැද භාගයේ දී නිකුත් වූ ව්යවසාය PHP එකක් වන අතර, එතැන් සිට මම එය අසා නැත. ඒවගේම තිබුණා: Ruby, MySQL, PostgreSQL, Java, Go, Python. නමුත් ප්‍රධාන monolith එක ColdFusion සහ SQL Server මත ධාවනය විය.

ගැටළු

සමාගමේ සේවකයින් සමඟ වැඩ කටයුතු සහ මුහුණ දුන් ගැටළු මොනවාදැයි මම වැඩි වැඩියෙන් කතා කළ විට, ගැටළු තාක්ෂණික ස්වභාවය පමණක් නොවන බව මට වැටහුණි. හරි, තාක්ෂණය පැරණියි - ඔවුන් එය මත වැඩ කළේ නැත, නමුත් කණ්ඩායම සමඟ සහ ක්රියාවලීන් සමඟ ගැටළු ඇති වූ අතර, සමාගම මෙය තේරුම් ගැනීමට පටන් ගත්තේය.

සාම්ප්‍රදායිකව, ඔවුන්ගේ තාක්‍ෂණ ශිල්පීන් මුල්ලක වාඩි වී යම් ආකාරයක වැඩක් කළහ. නමුත් වැඩි වැඩියෙන් ව්යාපාර ඩිජිටල් අනුවාදය හරහා යන්නට පටන් ගත්තේය. එබැවින්, මම වැඩ කිරීමට පටන් ගැනීමට පෙර අවසන් වසර තුළ, සමාගම තුළ නව අය පෙනී සිටියහ: අධ්යක්ෂ මණ්ඩලය, CTO, CPO සහ QA අධ්යක්ෂ. එනම්, සමාගම තාක්ෂණික අංශයේ ආයෝජනය කිරීමට පටන් ගත්තේය.

බර උරුමයක සලකුණු තිබුණේ පද්ධතිවල පමණක් නොවේ. සමාගමට උරුම ක්‍රියාවලීන්, උරුම පුද්ගලයින්, උරුම සංස්කෘතිය තිබුණි. මේ සියල්ල වෙනස් කිරීමට සිදු විය. එය අනිවාර්යයෙන්ම කම්මැලි නොවනු ඇතැයි මම සිතුවෙමි, එය උත්සාහ කිරීමට තීරණය කළෙමි.

දවස් දෙකකට කලින්

නව රැකියාවක් ආරම්භ කිරීමට දින දෙකකට පෙර, මම කාර්යාලයට පැමිණ, අවසාන ලියකියවිලි පුරවා, කණ්ඩායම මුණගැසුණු අතර, එම අවස්ථාවේ කණ්ඩායම යම් ගැටලුවක් සමඟ පොරබදමින් සිටින බව දැනගත්තා. එය සාමාන්‍ය පිටු පැටවීමේ කාලය තත්පර 4 දක්වා, එනම් 2 වතාවක් දක්වා ඉහළ යාමයි.

ප්රස්ථාරය අනුව විනිශ්චය කිරීම, යමක් පැහැදිලිව සිදු වූ අතර, එය කුමක්ද යන්න පැහැදිලි නැත. ගැටළුව දත්ත මධ්‍යස්ථානයේ ජාල ප්‍රමාදය බව පෙනී ගියේය: දත්ත මධ්‍යස්ථානයේ 5 ms ප්‍රමාදය පරිශීලකයින් සඳහා තත්පර 2 ක් බවට පත් විය. මෙය සිදු වූයේ මන්දැයි මම නොදනිමි, නමුත් ඕනෑම අවස්ථාවක ගැටළුව දත්ත මධ්‍යස්ථානයේ ඇති බව දැනගන්නට ලැබුණි.

පළමු දිනයේ

දින දෙකක් ගෙවී ගිය අතර, මගේ පළමු වැඩ කරන දිනයේදී ගැටලුව පහව ගොස් නැති බව මම සොයා ගතිමි.

දින දෙකක් සඳහා, පරිශීලකයන්ගේ පිටු සාමාන්‍යයෙන් තත්පර 4 කින් පූරණය වේ. මම අහනවා ප්‍රශ්නය මොකක්ද කියලා හොයාගත්තද කියලා.

- ඔව්, අපි ටිකට් එකක් විවෘත කළා.
- හා?
- හොඳයි, ඔවුන් තවමත් අපට පිළිතුරු දුන්නේ නැත.

ඊට පස්සේ මට තේරුණා මට කලින් කියපු හැම දෙයක්ම මට සටන් කිරීමට සිදු වූ අයිස් කන්දේ කුඩා ඉඟියක් පමණක් බව.

මෙයට ඉතා හොඳින් ගැලපෙන හොඳ උපුටා දැක්වීමක් තිබේ:

"සමහර විට තාක්ෂණය වෙනස් කිරීමට ඔබ සංවිධානය වෙනස් කළ යුතුය."

නමුත් මම වසරේ කාර්යබහුලම කාලය තුළ වැඩ ආරම්භ කළ බැවින්, ගැටලුව විසඳීම සඳහා විකල්ප දෙකම දෙස බැලීමට සිදු විය: ඉක්මන් සහ දිගු කාලීන. සහ දැන් තීරණාත්මක දේ සමඟ ආරම්භ කරන්න.

තුන්වන දිනය

ඉතින්, පැටවීම තත්පර 4 ක් පවතින අතර, 13 සිට 15 දක්වා විශාලතම උච්ච වේ.

මෙම කාල පරිච්ෙඡ්දය තුළ තුන්වන දින, බාගත කිරීමේ වේගය මෙලෙස දිස් විය:

මගේ දෘෂ්ටි කෝණයෙන්, කිසිවක් සම්පූර්ණයෙන්ම සාර්ථක වූයේ නැත. අනිත් හැමෝගෙම පැත්තෙන් බැලුවොත් වෙනදට වඩා ටිකක් හෙමින් තමයි දුවන්නෙ. නමුත් එය එසේ සිදු නොවේ - එය බරපතල ගැටළුවකි.

මම කණ්ඩායමට ඒත්තු ගැන්වීමට උත්සාහ කළ අතර, ඔවුන් පිළිතුරු දුන්නේ ඔවුන්ට තවත් සේවාදායකයන් අවශ්‍ය බවයි. මෙය ඇත්ත වශයෙන්ම ගැටලුවට විසඳුමකි, නමුත් එය සෑම විටම එකම හා වඩාත්ම ඵලදායී නොවේ. මම ඇහුවා සර්වර් මදි ඇයි, ට්‍රැෆික් එකේ පරිමාව කීයද කියලා. මම දත්ත උපුටා ගත් අතර අපට තත්පරයකට ආසන්න වශයෙන් ඉල්ලීම් 150 ක් ඇති බව සොයා ගත් අතර, එය ප්‍රතිපත්තිමය වශයෙන් සාධාරණ සීමාවන් තුළට වැටේ.

නමුත් ඔබ නිවැරදි පිළිතුර ලබා ගැනීමට පෙර, ඔබ නිවැරදි ප්‍රශ්නය ඇසිය යුතු බව අප අමතක නොකළ යුතුය. මගේ ඊළඟ ප්‍රශ්නය වූයේ: අපට ඉදිරිපස සේවාදායකයන් කීයක් තිබේද? පිළිතුර "මාව ටිකක් අවුල් කළා" - අපට ඉදිරිපස සේවාදායකයන් 17 ක් තිබුණි!

— මම අහන්න ලැජ්ජයි, නමුත් 150 න් 17 න් බෙදුවොත් 8ක් විතර දෙනවද? ඔබ කියන්නේ සෑම සේවාදායකයක්ම තත්පරයකට ඉල්ලීම් 8 ක් ලබා දෙන බවත්, හෙට තත්පරයට ඉල්ලීම් 160 ක් ඇත්නම්, අපට තවත් සේවාදායකයන් 2 ක් අවශ්‍ය වනු ඇති බවත්?

ඇත්ත වශයෙන්ම, අපට අමතර සේවාදායකයන් අවශ්‍ය නොවීය. විසඳුම කේතය තුළම සහ මතුපිටින්:

var currentClass = classes.getCurrentClass();
return currentClass;

උත්සවයක් තිබුණා getCurrentClass(), වෙබ් අඩවියේ ඇති සෑම දෙයක්ම පන්තියක සන්දර්භය තුළ වැඩ කරන නිසා - එය හරි. මේ සඳහා සෑම පිටුවකම එක් කාර්යයක් තිබුණි ඉල්ලීම් 200+.

මේ ආකාරයෙන් විසඳුම ඉතා සරල විය, ඔබට කිසිවක් නැවත ලිවීමට පවා සිදු නොවීය: එකම තොරතුරු නැවත ඉල්ලන්න එපා.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

මම ගොඩක් සතුටු වුණා මොකද මම තීරණය කළා තුන්වෙනි දවසේදී මම ප්‍රධාන ප්‍රශ්නය හොයාගත්තා කියලා. මම බොළඳ වුවත්, මෙය බොහෝ ගැටලුවලින් එකක් පමණි.

නමුත් මෙම පළමු ගැටළුව විසඳීමෙන් ප්‍රස්ථාරය බෙහෙවින් අඩු විය.

ඒ අතරම, අපි වෙනත් ප්‍රශස්තිකරණයන් කරමින් සිටියෙමු. සකස් කළ හැකි බොහෝ දේ පෙනෙන්නට තිබුණි. උදාහරණයක් ලෙස, එම තුන්වන දිනයේදී මම පද්ධතියේ හැඹිලියක් ඇති බව සොයාගත්තා (මුලින්ම මම සිතුවේ සියලුම ඉල්ලීම් කෙලින්ම දත්ත ගබඩාවෙන් පැමිණෙන බවයි). මට හැඹිලියක් ගැන සිතන විට, මට සම්මත Redis හෝ Memcached මතක් වේ. නමුත් මම පමණක් එසේ සිතුවෙමි, මන්ද එම පද්ධතිය කෑෂිං සඳහා MongoDB සහ SQL සේවාදායකය භාවිතා කළ බැවිනි - දත්ත කියවා ඇති එකම එක.

දහවන දිනය

පළමු සතියේ මම දැන් විසඳිය යුතු ගැටළු සමඟ කටයුතු කළෙමි. දෙවන සතියේ කොහේ හරි, මම කණ්ඩායම සමඟ සන්නිවේදනය කිරීමට, සිදුවන්නේ කුමක්ද සහ සමස්ත ක්‍රියාවලිය සිදුවන්නේ කෙසේදැයි බැලීමට පළමු වරට නැගී සිටීමට පැමිණියෙමි.

රසවත් දෙයක් නැවතත් සොයා ගන්නා ලදී. කණ්ඩායම සමන්විත වූයේ: 18 සංවර්ධකයින්; පරීක්ෂකයින් 8 ක්; කළමනාකරුවන් 3 ක්; 2 ගෘහ නිර්මාණ ශිල්පීන්. ඔවුන් සියල්ලෝම පොදු චාරිත්‍ර වාරිත්‍රවලට සහභාගී වූහ, එනම් සෑම උදෑසනකම 30 දෙනෙකුට වැඩි පිරිසක් නැගී සිටිමින් ඔවුන් කළ දේ පැවසූහ. රැස්වීමට විනාඩි 5ක් හෝ 15ක් ගත නොවූ බව පැහැදිලිය. හැමෝම එක එක සිස්ටම් වල වැඩ කරන නිසා කවුරුත් කාටවත් ඇහුම්කන් දුන්නේ නෑ. මෙම ආකෘතියේ දී, මනමාල සැසියක් සඳහා පැයකට ප්රවේශපත් 2-3 ක් දැනටමත් හොඳ ප්රතිඵලය විය.

අපි මුලින්ම කළේ කණ්ඩායම නිෂ්පාදන රේඛා කිහිපයකට බෙදීමයි. විවිධ අංශ සහ පද්ධති සඳහා, අපි සංවර්ධකයින්, පරීක්ෂකයින්, නිෂ්පාදන කළමනාකරුවන් සහ ව්‍යාපාර විශ්ලේෂකයින් ඇතුළත් වෙනම කණ්ඩායම් වෙන් කළෙමු.

ප්රතිඵලයක් වශයෙන් අපට ලැබුණේ:

• නැගී සිටීම් සහ රැලි අඩු කිරීම.
• නිෂ්පාදනය පිළිබඳ විෂය දැනුම.
• හිමිකාරිත්වය පිළිබඳ හැඟීමක්. මිනිසුන් සෑම විටම පද්ධති සමඟ ටින්කර් කිරීමට භාවිතා කරන විට, වෙනත් කෙනෙකුට බොහෝ විට ඔවුන්ගේ දෝෂ සමඟ වැඩ කිරීමට සිදුවනු ඇති නමුත් තමන්ම නොවන බව ඔවුන් දැන සිටියහ.
• කණ්ඩායම් අතර සහයෝගීතාව. QA මීට පෙර ක්‍රමලේඛකයින් සමඟ එතරම් සන්නිවේදනය නොකළ බව අමුතුවෙන් කිව යුතු නැත, නිෂ්පාදිතය තමන්ගේම දෙයක් කළේය. දැන් ඔවුන්ට පොදු වගකීමක් ඇත.

අපි ප්‍රධාන වශයෙන් අවධානය යොමු කළේ කාර්යක්ෂමතාව, ඵලදායිතාව සහ ගුණාත්මකභාවය - කණ්ඩායමේ පරිවර්තනයත් සමඟ අපි විසඳීමට උත්සාහ කළ ගැටළු මේවාය.

එකොළොස් දිනය

කණ්ඩායම් ව්‍යුහය වෙනස් කිරීමේ ක්‍රියාවලියේදී, ගණන් කරන ආකාරය මම සොයා ගත්තෙමි කතාවලකුණු. 1 SP එක දිනකට සමාන වූ අතර, සෑම ටිකට්පතකම සංවර්ධන සහ QA යන දෙකම සඳහා SP, එනම් අවම වශයෙන් SP 2ක් අඩංගු විය.

මම මෙය සොයාගත්තේ කෙසේද?

අපට දෝෂයක් හමු විය: එක් වාර්තාවක, වාර්තාව අවශ්‍ය කාල සීමාවේ ආරම්භක සහ අවසන් දිනය ඇතුළත් කර ඇති අතර, අවසාන දිනය සැලකිල්ලට නොගනී. එනම්, ඉල්ලීමේ කොතැනක හෝ තිබුණේ <= නොව, සරලව <. මට කිව්වා මේක Story Points තුනක්, ඒ කියන්නේ 3 දින.

මෙයින් පසු අපි:

• Story Points ශ්‍රේණිගත කිරීමේ ක්‍රමය සංශෝධනය කර ඇත. දැන් පද්ධතිය හරහා ඉක්මනින් ගමන් කළ හැකි සුළු දෝෂ සඳහා නිවැරදි කිරීම් වේගයෙන් පරිශීලකයා වෙත ළඟා වේ.
• අපි සංවර්ධනය සහ පරීක්ෂා කිරීම සඳහා අදාළ ප්‍රවේශපත්‍ර ඒකාබද්ධ කිරීමට පටන් ගත්තෙමු. මීට පෙර, සෑම ප්‍රවේශ පත්‍රයක්ම, සෑම දෝෂයක්ම සංවෘත පරිසර පද්ධතියක් විය, වෙනත් කිසිවක් සමඟ බැඳී නැත. එක් පිටුවක බොත්තම් තුනක් වෙනස් කිරීම පිටුවකට එක් ස්වයංක්‍රීය පරීක්ෂණයක් වෙනුවට විවිධ QA ක්‍රියාවලි තුනක් සහිත විවිධ ප්‍රවේශපත්‍ර තුනක් විය හැකිය.
• අපි ශ්රම පිරිවැය ඇස්තමේන්තු කිරීම සඳහා ප්රවේශයක් මත සංවර්ධකයින් සමඟ වැඩ කිරීමට පටන් ගත්තෙමු. එක් බොත්තමක් වෙනස් කිරීමට දින තුනක් විහිළුවක් නොවේ.

විසිවන දිනය

පළමු මාසයේ මැද කොහේ හරි, තත්වය ටිකක් ස්ථාවර විය, මම මූලික වශයෙන් සිදුවන්නේ කුමක්දැයි වටහාගෙන, දැනටමත් අනාගතය දෙස බැලීමට සහ දිගුකාලීන විසඳුම් ගැන සිතීමට පටන් ගත්තා.

දිගු කාලීන ඉලක්ක:

• කළමනාකරණය කළ වේදිකාව. සෑම පිටුවකම ඉල්ලීම් සිය ගණනක් බරපතල නොවේ.
• පුරෝකථනය කළ හැකි ප්රවණතා. බැලූ බැල්මට වෙනත් ප්‍රමිතික සමඟ සහසම්බන්ධ නොවූ ආවර්තිතා මාර්ග තදබදයක් තිබුණි - මෙය සිදු වූයේ මන්දැයි අපට තේරුම් ගැනීමට සහ අනාවැකි කීමට ඉගෙන ගැනීමට අවශ්‍ය විය.
• වේදිකාව පුළුල් කිරීම. ව්‍යාපාරය නිරන්තරයෙන් වර්ධනය වෙමින් පවතී, වැඩි වැඩියෙන් පරිශීලකයින් පැමිණේ, ගමනාගමනය වැඩි වේ.

අතීතයේ බොහෝ විට මෙසේ කියන ලදී. “සියල්ල [භාෂාව/ රාමුව තුළ] නැවත ලියමු, සියල්ල හොඳින් ක්‍රියාත්මක වනු ඇත!”

බොහෝ අවස්ථාවලදී මෙය ක්රියා නොකරයි, නැවත ලිවීම කිසිසේත්ම ක්රියා කරයි නම් හොඳයි. එබැවින්, අපට මාර්ග සිතියමක් නිර්මාණය කිරීමට අවශ්‍ය විය - ව්‍යාපාරික අරමුණු සාක්ෂාත් කර ගන්නා ආකාරය (අපි කරන්නේ කුමක්ද සහ ඇයි) පියවරෙන් පියවර නිදර්ශනය කරන නිශ්චිත උපාය මාර්ගයක්:

• ව්යාපෘතියේ මෙහෙවර සහ අරමුණු පිළිබිඹු කරයි;
• ප්රධාන අරමුණු සඳහා ප්රමුඛත්වය දෙයි;
• ඒවා සාක්ෂාත් කර ගැනීම සඳහා කාලසටහනක් අඩංගු වේ.

මෙයට පෙර කිසිවකු කිසියම් වෙනසක් සිදු කිරීමේ අරමුණ ගැන කණ්ඩායම සමඟ කතා කර තිබුණේ නැත. මේ සඳහා නිවැරදි සාර්ථක ප්‍රමිතික අවශ්‍ය වේ. සමාගමේ ඉතිහාසයේ ප්රථම වතාවට අපි තාක්ෂණික කණ්ඩායම සඳහා KPIs සකස් කර ඇති අතර, මෙම දර්ශකයන් සංවිධානාත්මක ඒවාට බැඳී ඇත.

එනම්, ආයතනික KPIs කණ්ඩායම් විසින් සහය දක්වනු ලබන අතර කණ්ඩායම් KPIs සඳහා තනි තනි KPIs විසින් සහය දක්වයි. එසේ නොමැති නම්, තාක්ෂණික කේපීඅයි සංවිධානාත්මක ඒවා සමඟ සමපාත නොවන්නේ නම්, සෑම කෙනෙකුම තමන් මත බ්ලැන්කට්ටුව ඇද ගනී.

උදාහරණයක් ලෙස, ආයතනික KPI වලින් එකක් නව නිෂ්පාදන හරහා වෙළඳපල කොටස වැඩි කරයි.

තවත් නව නිෂ්පාදන ලබා ගැනීමේ ඉලක්කයට ඔබට සහාය විය හැක්කේ කෙසේද?

• පළමුව, අඩුපාඩු නිවැරදි කිරීම වෙනුවට නව නිෂ්පාදන සංවර්ධනය කිරීමට වැඩි කාලයක් ගත කිරීමට අපට අවශ්‍යය. මෙය මැනීමට පහසු තාර්කික විසඳුමකි.
• දෙවනුව, අපට ගනුදෙනු පරිමාව වැඩි කිරීමට සහාය වීමට අවශ්‍යයි, මන්ද වෙළඳපල කොටස වැඩි වන තරමට පරිශීලකයින් වැඩි වන අතර ඒ අනුව වැඩි තදබදයක් ඇති වේ.

එවිට කණ්ඩායම තුළ ක්‍රියාත්මක කළ හැකි තනි කේපීඅයි, උදාහරණයක් ලෙස, ප්‍රධාන දෝෂ ඇති ස්ථානයේ පවතිනු ඇත. ඔබ මෙම කොටස කෙරෙහි විශේෂයෙන් අවධානය යොමු කරන්නේ නම්, ඔබට අඩු අඩුපාඩු ඇති බවට වග බලා ගත හැකි අතර, පසුව නව නිෂ්පාදන සංවර්ධනය කිරීමට සහ ආයතනික KPI වලට සහාය වීම සඳහා කාලය වැඩි වේ.

මේ අනුව, නැවත ලිවීමේ කේතය ඇතුළුව සෑම තීරණයක්ම, සමාගම අප වෙනුවෙන් තබා ඇති නිශ්චිත ඉලක්ක සඳහා සහාය විය යුතුය (සංවිධානාත්මක වර්ධනය, නව විශේෂාංග, බඳවා ගැනීම්).

මෙම ක්‍රියාවලිය අතරතුර, සිත්ගන්නා කරුණක් අනාවරණය වූ අතර, එය තාක්‍ෂණ ශිල්පීන් සඳහා පමණක් නොව, පොදුවේ සමාගම තුළ ප්‍රවෘත්ති බවට පත් විය: සියලුම ටිකට්පත් අවම වශයෙන් එක් KPI වෙත අවධානය යොමු කළ යුතුය. එනම්, යම් නිෂ්පාදනයක් නව විශේෂාංගයක් සෑදීමට අවශ්‍ය යැයි පවසන්නේ නම්, පළමු ප්‍රශ්නය ඇසිය යුතුය: “මෙම විශේෂාංගයට KPI සහාය දෙන්නේ කුමක් ද?” එසේ නොවේ නම්, කණගාටුයි - එය අනවශ්ය අංගයක් ලෙස පෙනේ.

දින තිස්

මාසය අවසානයේදී, මම තවත් සූක්ෂ්මතාවයක් සොයා ගත්තෙමි: මගේ Ops කණ්ඩායමේ කිසිවෙක් අප සේවාදායකයින් සමඟ ඇති කර ගන්නා ගිවිසුම් දැක නැත. ඔබට සම්බන්ධතා බැලීමට අවශ්‍ය වන්නේ මන්දැයි ඔබට ඇසිය හැක.

• පළමුව, SLAs ගිවිසුම් වල සඳහන් කර ඇති බැවිනි.
• දෙවනුව, SLAs සියල්ල වෙනස් ය. සෑම සේවාදායකයෙක්ම තමාගේම අවශ්යතා සමඟ පැමිණි අතර, විකුණුම් දෙපාර්තමේන්තුව නොබලා අත්සන් කළේය.

තවත් සිත්ගන්නා සුළු කරුණක් නම්, විශාලතම සේවාදායකයෙකු සමඟ ඇති කොන්ත්‍රාත්තුවේ සඳහන් වන්නේ වේදිකාව විසින් සහාය දක්වන සියලුම මෘදුකාංග අනුවාද n-1 විය යුතු බවයි, එනම් නවතම අනුවාදය නොව අවසාන එක.

මෙම වේදිකාව ColdFusion සහ SQL Server 1 මත පදනම් වූවක් නම්, ජූලි මාසයේදී කිසිසේත්ම සහාය නොදක්වන ලදී නම්, අප n-2008 සිට කොපමණ දුරින් සිටියාද යන්න පැහැදිලිය.

දින හතළිස් පහ

දෙවන මාසයේ මැද භාගයේදී පමණ මට වාඩි වී කිරීමට ප්රමාණවත් කාලයක් තිබුණි අගයඇළසිතියම් ගත සම්පූර්ණ ක්රියාවලිය සඳහා සම්පූර්ණයෙන්ම. නිෂ්පාදනයක් නිර්මාණය කිරීමේ සිට පාරිභෝගිකයා වෙත ලබා දීම දක්වා ගත යුතු අවශ්‍ය පියවර මේවා වන අතර ඒවා හැකිතාක් විස්තරාත්මකව විස්තර කළ යුතුය.

ඔබ ක්‍රියාවලිය කුඩා කැබලිවලට කඩා වැඩි කාලයක් ගතවන්නේ කුමක්ද, ප්‍රශස්ත කළ හැකි, වැඩිදියුණු කළ හැකි දේ ආදිය බලන්න. උදාහරණයක් ලෙස, නිෂ්පාදන ඉල්ලීමක් මනාලනය හරහා යාමට කොපමණ කාලයක් ගතවේද, එය සංවර්ධකයෙකුට ගත හැකි ප්‍රවේශපත්‍රයකට ළඟා වන්නේ කවදාද, QA, ආදිය. එබැවින් ඔබ එක් එක් තනි පියවර දෙස විස්තරාත්මකව බලා ප්‍රශස්ත කළ හැකි දේ ගැන සිතන්න.

මම මෙය කළ විට, කරුණු දෙකක් මගේ ඇසට හසු විය:

• ප්‍රවේශපත්‍රවල ඉහළ ප්‍රතිශතයක් QA වෙතින් ආපසු සංවර්ධකයින් වෙත ආපසු;
• පුල් ඉල්ලීම් සමාලෝචන සඳහා දිගු කාලයක් ගත විය.

ගැටලුව වූයේ මේවා මෙවැනි නිගමන වීමයි: එය බොහෝ කාලයක් ගත වන බව පෙනේ, නමුත් කොපමණ කාලයක් ගතවේදැයි අපට විශ්වාස නැත.

"ඔබට මැනිය නොහැකි දේ වැඩිදියුණු කළ නොහැක."

ගැටලුව කෙතරම් බරපතළද යන්න සාධාරණීකරණය කරන්නේ කෙසේද? එය දින හෝ පැය නාස්ති කරනවාද?

මෙය මැනීමට, අපි ජිරා ක්‍රියාවලියට පියවර කිහිපයක් එක් කළෙමු: එක් එක් ප්‍රවේශ පත්‍රය කොපමණ වේලාවක් බලා සිටිනවාද සහ එය නිශ්චිත පියවරකට කොපමණ වාර ගණනක් නැවත පැමිණේදැයි මැනීමට “dev සඳහා සූදානම්” සහ “QA සඳහා සූදානම්”.

සමාලෝචනය සඳහා සාමාන්‍ය ප්‍රවේශපත්‍ර කීයක් තිබේදැයි දැන ගැනීමට අපි “සමාලෝචනයේ” ද එකතු කළ අතර, මෙයින් ඔබට නැටුම් ආරම්භ කළ හැකිය. අපට පද්ධති ප්‍රමිතික තිබුණි, දැන් අපි නව ප්‍රමිතික එකතු කර මැනීමට පටන් ගත්තෙමු:

• ක්රියාවලි කාර්යක්ෂමතාව: කාර්ය සාධනය සහ සැලසුම් කරන ලද / ලබා දී ඇත.
• ක්රියාවලියේ ගුණාත්මකභාවය: දෝෂ සංඛ්යාව, QA සිට දෝෂ.

එය ඇත්තෙන්ම හොඳින් සිදුවන්නේ කුමක්ද සහ හොඳ නොවන්නේ කුමක්ද යන්න තේරුම් ගැනීමට උපකාරී වේ.

පනස්වෙනි දවස

ඇත්ත වශයෙන්ම, මේ සියල්ල හොඳ සහ සිත්ගන්නා සුළුය, නමුත් දෙවන මාසය අවසානයේදී යමක් සිදු වූ අතර, ප්‍රතිපත්තිමය වශයෙන්, මම එවැනි පරිමාණයක් අපේක්ෂා නොකළද, පුරෝකථනය කළ හැකි විය. ඉහළ කළමනාකාරීත්වය වෙනස් වූ නිසා මිනිස්සු යන්න පටන් ගත්තා. නව පුද්ගලයින් කළමනාකරණයට පැමිණ සියල්ල වෙනස් කිරීමට පටන් ගත් අතර පැරණි අය ඉවත් වූහ. සාමාන්‍යයෙන් වසර කිහිපයක් පැරණි සමාගමක, සෑම කෙනෙකුම මිතුරන් වන අතර සෑම කෙනෙකුම එකිනෙකා හඳුනයි.

මෙය අපේක්ෂා කළ නමුත් දොට්ට දැමීම්වල පරිමාණය අනපේක්ෂිත විය. නිදසුනක් වශයෙන්, සතියක් තුළ කණ්ඩායම් නායකයින් දෙදෙනෙකු එකවරම ඔවුන්ගේ නිදහස් කැමැත්තෙන් ඉල්ලා අස්වීම් ඉදිරිපත් කරන ලදී. එමනිසා, මට වෙනත් ගැටළු අමතක කිරීමට පමණක් නොව, අවධානය යොමු කිරීමට සිදු විය කණ්ඩායමක් නිර්මාණය කිරීම. මෙය විසඳීමට දිගු හා දුෂ්කර ගැටලුවකි, නමුත් එය සමඟ කටයුතු කිරීමට සිදු වූයේ මට ඉතිරිව සිටින (හෝ ඔවුන්ගෙන් බොහෝ දෙනෙක්) බේරා ගැනීමට අවශ්‍ය වූ බැවිනි. කණ්ඩායමේ චිත්ත ධෛර්යය පවත්වා ගැනීම සඳහා මිනිසුන් ඉවත්ව ගිය බවට කෙසේ හෝ ප්‍රතිචාර දැක්වීම අවශ්‍ය විය.

න්‍යායාත්මකව, මෙය හොඳයි: කණ්ඩායමේ කුසලතා ඇගයීමට සහ පිරිස් ප්‍රතිස්ථාපනය කළ හැකි සම්පූර්ණ Carte blanche ඇති නව පුද්ගලයෙකු පැමිණේ. ඇත්ත වශයෙන්ම, ඔබට බොහෝ හේතු නිසා නව පුද්ගලයින් ගෙන්වා ගත නොහැක. ශේෂය සෑම විටම අවශ්ය වේ.

• පැරණි සහ අලුත්. වෙනස් කරන්න පුළුවන් වයසක අය තියාගෙන මෙහෙයුමට සහයෝගය දෙන්න ඕන. නමුත් ඒ සමඟම, අපි නව රුධිරය ගෙන ඒමට අවශ්යයි, අපි එය ටිකක් පසුව කතා කරමු.
• අත්දැකීමක්. අපිත් එක්ක වැඩ කරන්න ආසාවෙන් ඉන්න හොඳ ජූනියර්ස්ලා එක්ක මම ගොඩක් කතා කළා. නමුත් කනිෂ්ඨයන්ට සහය වීමට සහ ඔවුන්ට උපදේශකයින් ලෙස කටයුතු කිරීමට ප්‍රමාණවත් ජ්‍යෙෂ්ඨයන් නොසිටි නිසා මට ඔවුන් භාර ගැනීමට නොහැකි විය. මුලින්ම ඉහළ අය බඳවා ගැනීමට අවශ්ය වූ අතර පසුව පමණක් තරුණයින් බඳවා ගැනීමට අවශ්ය විය.
• කැරට් සහ පොල්ල.

නිවැරදි සමබරතාවය කුමක්ද, එය නඩත්තු කරන්නේ කෙසේද, කී දෙනෙක් තබා ගත යුතුද, කොපමණ තල්ලු කළ යුතුද යන ප්‍රශ්නයට මා සතුව හොඳ පිළිතුරක් නොමැත. මෙය තනිකරම තනි පුද්ගල ක්‍රියාවලියකි.

පනස් එක් දිනය

මට ඇත්තේ කවුදැයි තේරුම් ගැනීමට මම කණ්ඩායම දෙස සමීපව බැලීමට පටන් ගත් අතර, නැවත වරක් මට සිහිපත් විය:

"බොහෝ ගැටලු මිනිසුන්ගේ ගැටළු වේ."

කණ්ඩායමට - Dev සහ Ops යන දෙකටම - විශාල ගැටළු තුනක් ඇති බව මට පෙනී ගියේය:

• වත්මන් තත්ත්වය පිළිබඳව තෘප්තිමත් වීම.
• වගකීමක් නොමැතිකම - මක්නිසාද යත්, ව්‍යාපාරයට බලපෑම් කිරීම සඳහා කිසිවකු රංගන ශිල්පීන්ගේ කාර්යයේ ප්‍රතිඵල ගෙනවිත් නැති බැවිනි.
• වෙනස් වීමට ඇති බිය.

වෙනස් වීම සැමවිටම ඔබව ඔබේ සුවපහසු කලාපයෙන් පිටතට ගෙන යන අතර, තරුණ අය වෙනස් වීමට අකමැති වන්නේ ඇයි දැයි ඔවුන්ට නොතේරෙන නිසා සහ ඔවුන්ට නොතේරෙන බැවිනි. මා අසා ඇති වඩාත් පොදු පිළිතුර නම්, "අපි කවදාවත් එහෙම කරලා නැහැ" යන්නයි. එපමණක් නොව, එය සම්පූර්ණ විකාරයක් කරා ළඟා විය - යමෙකු කෝපයට පත් නොවී සුළු වෙනස්කම් සිදු විය නොහැක. වෙනස්කම් ඔවුන්ගේ කාර්යයට කොතරම් බලපෑවද, මිනිසුන් පැවසුවේ “නැහැ, ඇයි? මේක හරියන්නේ නෑ."

නමුත් කිසිවක් වෙනස් නොකර ඔබට හොඳ විය නොහැක.

මම සේවකයෙකු සමඟ සම්පූර්ණයෙන්ම විකාර සංවාදයක් පැවැත්වූ අතර, ප්‍රශස්තකරණය සඳහා මගේ අදහස් මම ඔහුට කීවෙමි, ඔහු මට පැවසුවේ:
- ඔහ්, පසුගිය වසරේ අප සතුව තිබූ දේ ඔබ දුටුවේ නැත!
- ඉතින් කුමක් ද?
"දැන් ඒක ඉස්සරට වඩා ගොඩක් හොඳයි."
- ඉතින්, එය වඩා හොඳ විය නොහැකිද?
- කුමක් සඳහා ද?

හොඳ ප්‍රශ්නයක් - ඇයි? එය දැන් තිබුණාට වඩා හොඳ නම්, එවිට සෑම දෙයක්ම ප්රමාණවත් තරම් හොඳයි. මෙය වගකීමක් නොමැතිකමට මග පාදයි, එය ප්‍රතිපත්තිමය වශයෙන් සම්පූර්ණයෙන්ම සාමාන්‍ය දෙයකි. මම කිව්වා වගේ තාක්ෂණික කණ්ඩායම ටිකක් පැත්තකට වෙලා හිටියා. ඔවුන් පැවතිය යුතු බව සමාගම විශ්වාස කළ නමුත් කිසිවෙක් කිසිදා ප්‍රමිතීන් සකසා නැත. තාක්‍ෂණික සහය කිසි විටෙකත් SLA දුටුවේ නැත, එබැවින් එය කණ්ඩායමට තරමක් “පිළිගත හැකි” විය (මෙය මට වඩාත්ම බලපෑවේය):

• තත්පර 12 පැටවීම;
• එක් එක් නිකුතුව සඳහා විනාඩි 5-10 ක් අක්රිය වීම;
• තීරනාත්මක ගැටළු දෝශ නිරාකරණය සඳහා දින සහ සති ගත වේ;
• රාජකාරි කාර්ය මණ්ඩලය නොමැතිකම 24x7 / ඇමතුම.

අපි එය වඩා හොඳින් නොකරන්නේ මන්දැයි කිසිවෙකු කිසි විටෙකත් ඇසීමට උත්සාහ නොකළ අතර එය එසේ නොවිය යුතු බව කිසිවෙකුට වැටහුණේ නැත.

ප්‍රසාද දීමනාවක් ලෙස, තවත් එක් ගැටලුවක් විය: අත්දැකීම් නොමැතිකම. ජ්‍යෙෂ්ඨයන් ඉවත්ව ගිය අතර, ඉතිරි තරුණ කණ්ඩායම පසුගිය පාලනය යටතේ හැදී වැඩුණු අතර එයින් විෂ විය.

මේ සියල්ලට අමතරව, මිනිසුන් අසමත් වීමට හා අදක්ෂ ලෙස පෙනී සිටීමට බිය විය. මෙය ප්‍රකාශ වන්නේ, පළමුව, ඔවුන් ය කිසිම තත්වයක් යටතේ උදව් ඉල්ලා නැත. අපි කණ්ඩායම් වශයෙන් සහ තනි තනිව කී වතාවක් කතා කළාද, මම කිව්වා "ඔබ යමක් කරන්නේ කෙසේදැයි නොදන්නේ නම් ප්‍රශ්නයක් අසන්න" කියා. මට මා ගැන විශ්වාසයක් ඇති අතර මට ඕනෑම ගැටලුවක් විසඳිය හැකි බව දනිමි, නමුත් එයට කාලය ගතවනු ඇත. ඒ නිසා විනාඩි 10න් විසදන හැටි දන්න කෙනෙක්ගෙන් අහන්න පුලුවන්නම් අහන්නම්. ඔබට අත්දැකීම් අඩු වන තරමට ඔබ අසන්නට බිය වන්නේ ඔබ අදක්ෂයෙකු ලෙස සලකනු ඇතැයි ඔබ සිතන බැවිනි.

ප්‍රශ්න ඇසීමට ඇති මෙම බිය සිත්ගන්නාසුලු ආකාරවලින් විදහා දක්වයි. උදාහරණයක් ලෙස, ඔබ අසන්නේ: "ඔබ මෙම කාර්යය සමඟ කටයුතු කරන්නේ කෙසේද?" - "පැය කිහිපයක් ඉතිරිව ඇත, මම දැනටමත් අවසන් කරමි." ඊලග දවසෙ ආයෙත් ඇහුවම උත්තරේ හම්බෙනවා ඔක්කොම හරි කියලා, ඒත් එක ප්‍රශ්නයක් තිබුනා, අනිවාරෙන්ම දවස ඉවර වෙනකොට ලෑස්ති ​​වෙයි. තවත් දිනක් ගෙවී යන අතර, ඔබව බිත්තියට සවි කර යමෙකු සමඟ කතා කිරීමට බල කරන තුරු, මෙය දිගටම පවතී. පුද්ගලයෙකුට තමා විසින්ම ගැටලුවක් විසඳීමට අවශ්‍ය වේ; ඔහු එය තමා විසින්ම විසඳා නොගතහොත් එය විශාල අසාර්ථකත්වයක් වනු ඇතැයි ඔහු විශ්වාස කරයි.

ඒ නිසයි සංවර්ධකයින් ඇස්තමේන්තු පුම්බා ඇත. ඒ කතාවම තමයි, ඔවුන් යම් කාර්යයක් ගැන සාකච්ඡා කරන විට, ඔවුන් මට එවැනි රූපයක් ලබා දුන්නේ, මා පුදුමයට පත් විය. සංවර්ධකයාගේ ඇස්තමේන්තු වල, සංවර්ධකයාට QA වෙතින් ටිකට් පත ආපසු ලබා දෙන කාලය ඇතුළත් වන බව මට කීවේය, මන්ද ඔවුන් එහි දෝෂ සොයා ගන්නා නිසා සහ PR ගතවන කාලය සහ සමාලෝචනය කළ යුතු පුද්ගලයින් සිටින කාලය එය කාර්යබහුල වනු ඇත - එනම්, සෑම දෙයක්ම, හැකි ඕනෑම දෙයක්.

දෙවනුව, අදක්ෂයෙකු ලෙස පෙනී සිටීමට බිය වන පුද්ගලයින් අධි විශ්ලේෂණය. හරියටම කළ යුතු දේ ඔබ පවසන විට, එය ආරම්භ වන්නේ: "නැහැ, අපි ඒ ගැන මෙතන හිතුවොත් මොකද කරන්නේ?" මෙම අර්ථයෙන් ගත් කල, අපගේ සමාගම අද්විතීය නොවේ; මෙය තරුණයින් සඳහා සම්මත ගැටළුවකි.

ඊට ප්‍රතිචාර වශයෙන්, මම පහත ක්‍රම හඳුන්වා දුන්නෙමි.

• රීතිය විනාඩි 30 කි. ඔබට පැය භාගයකින් ගැටලුව විසඳිය නොහැකි නම්, උදව් කිරීමට යමෙකුගෙන් ඉල්ලා සිටින්න. මෙය විවිධ මට්ටමේ සාර්ථකත්වයන් සමඟ ක්‍රියා කරයි, මන්ද මිනිසුන් තවමත් අසන්නේ නැත, නමුත් අවම වශයෙන් ක්‍රියාවලිය ආරම්භ වී ඇත.
• සාරය හැර සියල්ල ඉවත් කරන්න, කාර්යයක් සම්පූර්ණ කිරීම සඳහා අවසාන දිනය ඇස්තමේන්තු කිරීමේදී, එනම්, කේතය ලිවීමට කොපමණ කාලයක් ගතවේද යන්න පමණක් සලකා බලන්න.
• ජීවිත කාලය පුරාම ඉගෙනීම අධික ලෙස විශ්ලේෂණය කරන අය සඳහා. එය මිනිසුන් සමඟ නිරන්තර වැඩ කිරීම පමණි.

හැටවන දිනය

මම මේ සියල්ල කරන අතරේ අයවැය ගණනය කිරීමට කාලයයි. ඇත්ත වශයෙන්ම, අපි අපේ මුදල් වියදම් කළ ස්ථානයේ බොහෝ රසවත් දේවල් සොයාගත්තා. උදාහරණයක් ලෙස, අපි එක් FTP සේවාදායකයක් සමඟ වෙනම දත්ත මධ්‍යස්ථානයක සම්පූර්ණ රාක්කයක්ම සිටි අතර එය එක් සේවාදායකයෙකු විසින් භාවිතා කරන ලදී. එය "... අපි ගියා, නමුත් ඔහු එසේ සිටියා, අපි ඔහුව වෙනස් කළේ නැහැ." එය මීට වසර 2 කට පෙරය.

විශේෂයෙන් උනන්දු වූයේ වලාකුළු සේවා සඳහා බිල්පතයි. ඉහළ වලාකුළු බිල්පත් සඳහා ප්රධාන හේතුව ඔවුන්ගේ ජීවිතයේ පළමු වරට සේවාදායකයන් වෙත අසීමිත ප්රවේශයක් ඇති සංවර්ධකයින් බව මම විශ්වාස කරමි. ඔවුන් ඇසීමට අවශ්ය නැත: "කරුණාකර මට පරීක්ෂණ සේවාදායකයක් දෙන්න," ඔවුන් විසින්ම එය ගත හැකිය. Plus, Facebook සහ Netflix ඊර්ෂ්‍යා කරන එවැනි සිසිල් පද්ධතියක් ගොඩනැගීමට සංවර්ධකයින්ට සැමවිටම අවශ්‍ය වේ.

නමුත් සංවර්ධකයින්ට සේවාදායකයන් මිලදී ගැනීමේ අත්දැකීමක් සහ අවශ්‍ය සේවාදායක ප්‍රමාණය තීරණය කිරීමේ කුසලතාවක් නොමැත, මන්ද ඔවුන්ට එය පෙර අවශ්‍ය නොවීය. තවද ඔවුන් සාමාන්‍යයෙන් පරිමාණය සහ කාර්ය සාධනය අතර වෙනස හොඳින් වටහා නොගනී.

ඉන්වෙන්ටරි ප්රතිඵල:

• අපි එකම දත්ත මධ්‍යස්ථානයෙන් පිටව ගියෙමු.
• අපි ලොග් සේවා 3ක් සමඟ ගිවිසුම අවසන් කළා. අපට ඔවුන්ගෙන් 5 දෙනෙක් සිටි නිසා - යමක් සමඟ සෙල්ලම් කිරීමට පටන් ගත් සෑම සංවර්ධකයෙක්ම අලුත් එකක් ගත්තා.
• AWS පද්ධති 7 ක් වසා දමන ලදී. නැවතත්, කිසිවෙකු මිය ගිය ව්‍යාපෘති නැවැත්වූයේ නැත; ඔවුන් සියල්ලෝම දිගටම වැඩ කළහ.
• මෘදුකාංග පිරිවැය 6 ගුණයකින් අඩු කරයි.

හැත්තෑ පස්වන දිනය

කාලය ගෙවී ගිය අතර මාස දෙකහමාරකින් මට අධ්‍යක්ෂ මණ්ඩලය හමුවීමට සිදු විය. අපගේ අධ්‍යක්ෂ මණ්ඩලය අනෙක් අයට වඩා හොඳ හෝ නරක නැත; සියලුම අධ්‍යක්ෂ මණ්ඩල මෙන් එයටත් සියල්ල දැන ගැනීමට අවශ්‍යයි. මිනිසුන් මුදල් ආයෝජනය කරන අතර, KPI කට්ටලයට අප කරන දේ කොතරම් දුරට ගැලපේද යන්න තේරුම් ගැනීමට අවශ්‍යයි.

අධ්‍යක්ෂ මණ්ඩලයට සෑම මසකම බොහෝ තොරතුරු ලැබේ: පරිශීලකයින් සංඛ්‍යාව, ඔවුන්ගේ වර්ධනය, ඔවුන් භාවිතා කරන සේවාවන් සහ කෙසේද, කාර්ය සාධනය සහ ඵලදායිතාව සහ අවසාන වශයෙන් සාමාන්‍ය පිටු පැටවීමේ වේගය.

එකම ප්‍රශ්නය නම් සාමාන්‍යය පිරිසිදු නපුර බව මම විශ්වාස කරමි. නමුත් මේක අධ්‍යක්ෂ මණ්ඩලයට පැහැදිලි කරන්න හරිම අමාරුයි. ඔවුන් සමස්ථ සංඛ්‍යා සමඟ ක්‍රියා කිරීමට පුරුදු වී සිටින අතර, උදාහරණයක් ලෙස, තත්පරයකට පැටවීමේ වාර ගණන පැතිරීම නොවේ.

මේ සම්බන්ධයෙන් සිත්ගන්නා කරුණු කිහිපයක් තිබුණි. උදාහරණයක් ලෙස, අපි අන්තර්ගතයේ වර්ගය අනුව වෙනම වෙබ් සේවාදායකයන් අතර ගමනාගමනය බෙදිය යුතු බව මම කීවෙමි.

එනම්, ColdFusion Jetty සහ nginx හරහා ගොස් පිටු දියත් කරයි. පින්තූර, JS සහ CSS ඔවුන්ගේම වින්‍යාසයන් සමඟ වෙනම nginx හරහා ගමන් කරයි. මේක මම කතා කරන තරමක් සම්මත පුරුද්දක් ලිවීය වසර කිහිපයකට පෙර. එහි ප්‍රතිඵලයක් වශයෙන්, පින්තූර ඉතා වේගයෙන් පටවන අතර, සාමාන්‍ය පැටවීමේ වේගය ms 200 කින් වැඩි වී ඇත.

මෙය සිදු වූයේ ප්‍රස්ථාරය ජෙටි සමඟ එන දත්ත මත පදනම්ව ගොඩනගා ඇති බැවිනි. එනම්, වේගවත් අන්තර්ගතය ගණනය කිරීමේදී ඇතුළත් නොවේ - සාමාන්ය අගය ඉහළ ගොස් ඇත. මෙය අපට පැහැදිලි විය, අපි සිනාසුණෙමු, නමුත් අපි යමක් කළේ ඇයි සහ තත්වය 12% කින් නරක අතට හැරුණේ මන්දැයි අපි අධ්‍යක්ෂ මණ්ඩලයට පැහැදිලි කරන්නේ කෙසේද?

දින අසූ පහ

තුන්වන මාසය අවසානයේදී, මම කිසිසේත් ගණන් නොගත් එක් දෙයක් ඇති බව මට වැටහුණි: කාලය. මම කතා කළ සෑම දෙයක් ගැනම කාලය ගතවේ.

මෙය මගේ සැබෑ සතිපතා දින දර්ශනයයි - වැඩ කරන සතියක්, ඉතා කාර්යබහුල නොවේ. හැමදේටම වෙලාව මදි. එමනිසා, නැවතත්, ඔබට ගැටළු සමඟ සාර්ථකව කටයුතු කිරීමට උපකාර වන පුද්ගලයින් බඳවා ගැනීමට අවශ්ය වේ.

නිගමනය

එපමණක් නොවේ. මෙම කතාවේදී, අපි නිෂ්පාදනය සමඟ වැඩ කළ ආකාරය සහ සාමාන්‍ය රැල්ලට සුසර කිරීමට උත්සාහ කළ ආකාරය හෝ අපි තාක්ෂණික සහාය ඒකාබද්ධ කළ ආකාරය හෝ වෙනත් තාක්ෂණික ගැටලු විසඳා ගත්තේ කෙසේද යන්න ගැන මට අවබෝධයක් ලැබී නැත. උදාහරණයක් ලෙස, දත්ත සමුදායේ විශාලතම වගු මත අප භාවිතා නොකරන බව මම අහම්බෙන් ඉගෙන ගත්තා SEQUENCE. අපට ස්වයං-ලිඛිත කාර්යයක් ඇත nextID, සහ එය ගනුදෙනුවකදී භාවිතා නොවේ.

අපට බොහෝ කාලයක් කතා කළ හැකි තවත් සමාන දේවල් මිලියනයක් තිබුණි. නමුත් තවමත් කිව යුතු වැදගත්ම දෙය සංස්කෘතියයි.

සංස්කෘතිය හෝ එහි නොමැතිකම අනෙක් සියලුම ගැටළු වලට මග පාදයි. අපි උත්සාහ කරන්නේ මිනිසුන් සිටින සංස්කෘතියක් ගොඩනැගීමටයි.

• අසාර්ථකත්වයට බිය නැත;
• වැරදි වලින් ඉගෙන ගන්න;
• වෙනත් කණ්ඩායම් සමඟ සහයෝගයෙන් කටයුතු කිරීම;
• මූලිකත්වය ගන්න;
• වගකීම ගන්න;
• ඉලක්කයක් ලෙස ප්රතිඵලය සාදරයෙන් පිළිගනිමු;
• සාර්ථකත්වය සමරමින්.

මේ සමඟ අනෙක් සියල්ල පැමිණෙනු ඇත.

ලියොන් ගිනි twitter එකේ, ෆේස්බුක් සහ මත මධ්යම.

උරුමය සම්බන්ධයෙන් උපාය මාර්ග දෙකක් තිබේ: ඕනෑම වියදමකින් එය සමඟ වැඩ කිරීමෙන් වළකින්න, නැතහොත් ඒ ආශ්‍රිත දුෂ්කරතා නිර්භීතව ජය ගන්න. අපි සී DevOpsConf අපි ක්‍රියාවලි සහ ප්‍රවේශයන් වෙනස් කරමින් දෙවන මාර්ගය ගනිමින් සිටිමු. අප හා එක්වන්න ප්රථම අදියර, තැපැල් ලැයිස්තුව и විදුලි පණිවුඩ, සහ අපි එක්ව DevOps සංස්කෘතියක් ක්‍රියාත්මක කරන්නෙමු.

මූලාශ්රය: www.habr.com