අපගේ සමාගම SRE කණ්ඩායමක් ඇතුළත් කිරීමේ ක්‍රියාවලියක යෙදී සිටී. මම මේ සම්පූර්ණ කතාවට ආවේ සංවර්ධන පැත්තෙන්. ක්‍රියාවලියේදී, මම වෙනත් සංවර්ධකයින් සමඟ බෙදා ගැනීමට අවශ්‍ය සිතුවිලි සහ තීක්ෂ්ණ බුද්ධිය ඉදිරිපත් කළෙමි. මෙම පරාවර්තන ලිපියෙන් මම කතා කරන්නේ සිදුවන්නේ කුමක්ද, එය සිදුවන්නේ කෙසේද සහ සෑම කෙනෙකුටම එය සමඟ දිගටම ජීවත් විය හැකි ආකාරය ගැන ය.
අපගේ අභ්‍යන්තර ඉසව්වේ කතා පදනම් කරගෙන ලියන ලද ලිපි මාලාවක අඛණ්ඩ පැවැත්ම :
2. කේතය ලෙස යටිතල පහසුකම්. (ඔයා මෙහෙයි)
3. C# මාදිලි භාවිතයෙන් Typescript ගිවිසුම් උත්පාදනය කිරීම. (ප්රගතියේ...)
4. Raft සම්මුති ඇල්ගොරිතමයට හැඳින්වීම. (ප්රගතියේ...)
...
අදහස් ක්‍රියාත්මක කරමින් SRE කණ්ඩායමක් නිර්මාණය කිරීමට අපි තීරණය කළෙමු . ඔවුන් තමන්ගේම සංවර්ධකයින් අතරින් ක්‍රමලේඛකයින් බඳවාගෙන ඔවුන්ව මාස කිහිපයක් පුහුණු කිරීමට යැව්වා.
කණ්ඩායමට පහත සඳහන් පුහුණු කාර්යයන් තිබුණි:
- බොහෝ දුරට Microsoft Azure හි කේත ආකාරයෙන් (Terraform සහ අවට ඇති සියල්ල) ඇති අපගේ යටිතල පහසුකම් විස්තර කරන්න.
- යටිතල පහසුකම් සමඟ වැඩ කරන ආකාරය සංවර්ධකයන්ට උගන්වන්න.
- රාජකාරි සඳහා සංවර්ධකයින් සූදානම් කරන්න.
අපි කේතය ලෙස යටිතල පහසුකම් සංකල්පය හඳුන්වා දෙන්නෙමු
ලෝකයේ සුපුරුදු ආකෘතියේ (සම්භාව්‍ය පරිපාලනය), යටිතල පහසුකම් පිළිබඳ දැනුම ස්ථාන දෙකක පිහිටා ඇත:
- එසේත් නැතිනම් විශේෂඥයන්ගේ හිසෙහි දැනුමේ ස්වරූපයෙන්.
- නැතහොත් මෙම තොරතුරු සමහර යතුරු ලියනයක ඇත, ඒවායින් සමහරක් විශේෂඥයින් දන්නා කරුණකි. නමුත් පිටස්තරයෙකුට (අපගේ මුළු කණ්ඩායමම හදිසියේ මිය ගියහොත්) ක්‍රියා කරන්නේ කුමක්ද සහ එය ක්‍රියා කරන්නේ කෙසේද යන්න සොයා ගැනීමට හැකි වනු ඇති බව සත්‍යයක් නොවේ. යන්ත්රයක් මත බොහෝ තොරතුරු තිබිය හැක: උපාංග, ක්‍රොන්ජොබ්, බිය ගැන්වීම (බලන්න. ) තැටිය සහ සිදුවිය හැකි දේ පිළිබඳ නිමක් නැති ලැයිස්තුවක්. ඇත්තටම වෙන්නේ මොකක්ද කියලා තේරුම් ගන්න අමාරුයි.
අවස්ථා දෙකේදීම, අප යැපීමට හසු වී සිටින බව අපට පෙනේ:
- හෝ මාරාන්තික, රෝගාබාධවලට ලක්වන, ආදරයෙන් බැඳීම, මනෝභාවය වෙනස් වීම සහ සරලව සේවයෙන් පහකිරීම් වැනි පුද්ගලයෙකුගෙන්;
- හෝ භෞතිකව වැඩ කරන යන්ත්‍රයකින්, එය ද වැටී, සොරකම් කර, විස්මයන් සහ අපහසුතාවයන් ඉදිරිපත් කරයි.
සෑම දෙයක්ම මිනිසාට කියවිය හැකි, නඩත්තු කළ හැකි, හොඳින් ලිඛිත කේතයකට පරිවර්තනය කළ යුතු බව නොකියයි.
මේ අනුව, යටිතල පහසුකම් කේතය ලෙස (Incfastructure as Code - IaC) යනු කේත ස්වරූපයෙන් පවතින සමස්ත යටිතල ව්යුහය පිළිබඳ විස්තරයක් මෙන්ම එය සමඟ වැඩ කිරීමට සහ එයින් සැබෑ යටිතල පහසුකම් ක්‍රියාත්මක කිරීමට අදාළ මෙවලම් වේ.
සියල්ල කේතයට පරිවර්තනය කරන්නේ ඇයි?මිනිසුන් යන්ත්‍ර නොවේ. ඔවුන්ට සියල්ල මතක නැත. පුද්ගලයෙකුගේ සහ යන්ත්රයේ ප්රතික්රියාව වෙනස් වේ. ස්වයංක්‍රීය ඕනෑම දෙයක් මිනිසා විසින් කරන ඕනෑම දෙයකට වඩා වේගවත් විය හැකිය. වැදගත්ම දෙය නම් සත්‍යයේ තනි මූලාශ්‍රයයි.
නව SRE ඉංජිනේරුවන් පැමිණෙන්නේ කොහෙන්ද?ඉතින්, අපි නව SRE ඉංජිනේරුවන් බඳවා ගැනීමට තීරණය කළ නමුත් ඔවුන් ලබා ගන්නේ කොහෙන්ද? නිවැරදි පිළිතුරු සමඟ වෙන්කරවා ගන්න () අපට කියයි: සංවර්ධකයින්ගෙන්. සියල්ලට පසු, ඔවුන් කේතය සමඟ වැඩ කරන අතර, ඔබ පරමාදර්ශී තත්වය ලබා ගනී.
අපගේ සමාගමෙන් පිටත පිරිස් වෙළඳපොලේ අපි ඔවුන් ගැන බොහෝ කාලයක් සෙව්වෙමු. නමුත් අපගේ ඉල්ලීම්වලට ගැලපෙන කිසිවෙක් අපට හමු නොවූ බව පිළිගත යුතුය. මට මගේම මිනිස්සු අතරේ හොයන්න වුණා.
ගැටළු යටිතල පහසුකම් කේතය ලෙස
දැන් අපි යටිතල ව්‍යූහය දෘඪ කේත කේතයක් බවට පත් කරන්නේ කෙසේද යන්න පිළිබඳ උදාහරණ බලමු. කේතය හොඳින් ලියා ඇත, උසස් තත්ත්වයේ, අදහස් සහ ඉන්ඩෙන්ටේෂන් සමඟ.
Terraforma වෙතින් උදාහරණ කේතය.
Ansible වෙතින් උදාහරණ කේතය.
මහත්වරුනි, එය ඉතා සරල නම්! අපි සැබෑ ලෝකයේ සිටින අතර, එය සැමවිටම ඔබව පුදුම කිරීමට, විස්මයන් සහ ගැටළු ඔබට ඉදිරිපත් කිරීමට සූදානම්ය. මෙහෙත් උන් නැතුව බෑ.
1. පළමු ගැටළුව වන්නේ බොහෝ අවස්ථාවලදී IaC යම් ආකාරයක dsl වේ.
සහ DSL, අනෙක් අතට, ව්යුහය පිළිබඳ විස්තරයකි. වඩාත් නිවැරදිව, ඔබ සතුව තිබිය යුතු දේ: Json, Yaml, ඔවුන්ගේම dsl සමඟ පැමිණි සමහර විශාල සමාගම්වල වෙනස් කිරීම් (HCL ටෙරාෆෝම් වල භාවිතා වේ).
කරදරය නම්, එහි එවැනි හුරුපුරුදු දේවල් පහසුවෙන් අඩංගු නොවීමයි:
- විචල්යයන්;
- කොන්දේසි;
- කොතැනක හෝ අදහස් නොමැත, උදාහරණයක් ලෙස, Json හි, පෙරනිමියෙන් ඒවා සපයා නැත;
- කාර්යයන්;
- සහ මම පන්ති, උරුමය සහ ඒ සියල්ල වැනි ඉහළ මට්ටමේ දේවල් ගැන කතා නොකරමි.
2. එවැනි කේතයේ දෙවන ගැටළුව වන්නේ බොහෝ විට එය විෂමජාතීය පරිසරයකි. සාමාන්යයෙන් ඔබ C# සමඟ වාඩි වී වැඩ කරන්න, i.e. එක් භාෂාවක්, එක් තොගයක්, එක් පරිසර පද්ධතියක් සමඟ. තවද මෙහි ඔබට අතිවිශාල විවිධ තාක්ෂණයන් ඇත.
python සමඟ bash Json ඇතුළු කරන යම් ක්‍රියාවලියක් දියත් කරන විට එය ඉතා සැබෑ තත්වයකි. ඔබ එය විශ්ලේෂණය කරන්න, එවිට වෙනත් උත්පාදක යන්ත්රයක් තවත් ගොනු 30 ක් නිෂ්පාදනය කරයි. මේ සියල්ල සඳහා, Go හි ලියා ඇති drone.io සඳහා ප්ලගිනයකින් එකට ඇද ගන්නා Azure Key Vault වෙතින් ආදාන විචල්යයන් ලැබෙන අතර, මෙම විචල්යයන් jsonnet ටෙම්ප්ලේට් එන්ජිමෙන් උත්පාදනය වීමේ ප්‍රතිඵලයක් ලෙස ජනනය වූ yaml හරහා ගමන් කරයි. ඔබට එවැනි විවිධ පරිසරයක් ඇති විට ඉතා හොඳින් විස්තර කර ඇති කේතයක් තිබීම තරමක් අපහසුය.
එක් කාර්යයක රාමුව තුළ සම්ප්රදායික සංවර්ධනය එක් භාෂාවක් සමඟ පැමිණේ. මෙන්න අපි භාෂා විශාල සංඛ්යාවක් සමඟ වැඩ කරන්නෙමු.
3. තුන්වන ගැටළුව වන්නේ සුසර කිරීමයි. අප වෙනුවෙන් සෑම දෙයක්ම කරන සංස්කාරකවරුන් (Ms Visual Studio, Jetbrains Rider) සිසිල් කිරීමට අපි පුරුදු වී සිටිමු. අනික අපි මෝඩ උනත් උන් කියයි අපි වැරදියි කියල. එය සාමාන්ය හා ස්වභාවික බව පෙනේ.
නමුත් අසල කොතැනක හෝ VSCode ඇත, එහි කෙසේ හෝ ස්ථාපනය කර ඇති, සහාය දක්වන හෝ සහය නොදක්වන ප්ලගීන කිහිපයක් තිබේ. නව අනුවාද නිකුත් වූ අතර සහය නොදක්වන ලදී. ශ්‍රිතයක් ක්‍රියාවට නැංවීම සඳහා සාමාන්ය සංක්‍රාන්තියක් (එය පැවතියද) සංකීර්ණ හා සුළු නොවන ගැටලුවක් බවට පත්වේ. විචල්‍යයක සරල නැවත නම් කිරීම යනු ගොනු දුසිමක ව්‍යාපෘතියක නැවත ධාවනය කිරීමයි. ඔහු ඔබට අවශ්‍ය දේ තැබුවොත් ඔබ වාසනාවන්තයි. ඇත්ත වශයෙන්ම, මෙහි සහ එහි පසුබිම් ආලෝකය ඇත, ස්වයංක්‍රීයව සම්පූර්ණ කිරීම තිබේ, කොහේ හරි හැඩතල ගැන්වීමක් ඇත (එය වින්ඩෝස් හි ටෙරාෆෝම් වලදී මට ක්‍රියා නොකළද).
මේ ලියන මොහොතේ 0.12 අනුවාදය සඳහා සහය දැක්වීමට තවමත් නිකුත් කර නැත, නමුත් එය නිකුත් කර මාස 3 ක් ගත වී ඇත.
අමතක කිරීමට කාලයයි මේ...
- නිදොස් කිරීම.
- නැවත සකස් කිරීමේ මෙවලම.
- ස්වයංක්‍රීයව සම්පූර්ණ කිරීම.
- සම්පාදනය කිරීමේදී දෝෂ හඳුනා ගැනීම.
එය හාස්‍යජනකයි, නමුත් මෙය සංවර්ධන කාලය වැඩි කරන අතර අනිවාර්යයෙන්ම සිදුවන දෝෂ සංඛ්‍යාව වැඩි කරයි.
නරකම දෙය නම්, අපට සිතීමට බල කෙරෙන්නේ ගොනු සැලසුම් කරන්නේ කෙසේද, ෆෝල්ඩර බවට පත් කරන්නේ කෙසේද, දිරාපත්වන්නේ කෙසේද, කේතය නඩත්තු කරන්නේ කෙසේද, කියවිය හැකි ආකාරය ගැන නොව, නමුත් මම මෙම විධානය නිවැරදිව ලියන්නේ කෙසේද යන්න ගැන, මම එය කෙසේ හෝ වැරදියට ලියා ඇති නිසා. .
ආරම්භකයකු ලෙස, ඔබ ටෙරාෆෝම් ඉගෙන ගැනීමට උත්සාහ කරන අතර, IDE ඔබට කිසිසේත්ම උදව් කරන්නේ නැත. Documentation තියෙද්දි ඇතුලට ගිහින් බලන්න. නමුත් ඔබ නව ක්‍රමලේඛන භාෂාවක් ඇතුල් කරන්නේ නම්, එවැනි වර්ගයක් ඇති බව IDE ඔබට කියනු ඇත, නමුත් එවැනි දෙයක් නොමැත. අවම වශයෙන් int හෝ string මට්ටමේ. මෙය බොහෝ විට ප්රයෝජනවත් වේ.
පරීක්ෂණ ගැන කුමක් කිව හැකිද?
ඔබ අසයි: "පරීක්ෂණ ගැන කුමක් කිව හැකිද, වැඩසටහන්කරුවන් මහත්වරුනි?" බැරෑරුම් අය නිෂ්පාදනයේ සෑම දෙයක්ම පරීක්ෂා කරති, එය දුෂ්කර ය. වෙබ් අඩවියෙන් ටෙරාෆෝම් මොඩියුලයක් සඳහා ඒකක පරීක්ෂණයක උදාහරණයක් මෙන්න .
ඔවුන්ට හොඳ ලියකියවිලි තිබේ. ලේඛනගත කිරීම සහ පුහුණුව සඳහා මයික්රොසොෆ්ට් ප්‍රවේශය සඳහා මම සැමවිටම කැමතියි. නමුත් මෙය පරිපූර්ණ කේතයක් නොවන බව තේරුම් ගැනීමට ඔබ බොබ් මාමා වීමට අවශ්‍ය නැත. දකුණට වලංගු කිරීම සටහන් කරන්න.
ඒකක පරීක්ෂණයක ගැටලුව නම් ඔබට සහ මට Json ප්‍රතිදානයේ නිවැරදි භාවය පරීක්ෂා කළ හැකි වීමයි. මම පරාමිති 5ක් දැම්මා, පේලි 2000ක් තියෙන Json පාද රෙද්දක් දුන්නා. මට මෙහි සිදුවන්නේ කුමක්ද යන්න විශ්ලේෂණය කළ හැකිය, පරීක්ෂණ ප්‍රතිඵලය වලංගු කරන්න...
Go හි Json විග්‍රහ කිරීම අපහසුය. තවද ඔබ Go හි ලිවීමට අවශ්‍ය වේ, මන්ද Go හි ඇති ටෙරාෆෝම් ඔබ ලියන භාෂාවෙන් පරීක්ෂා කිරීම සඳහා හොඳ භාවිතයකි. කේතයේ සංවිධානයම ඉතා දුර්වලයි. ඒ අතරම, මෙය පරීක්ෂා කිරීම සඳහා හොඳම පුස්තකාලය වේ.
මයික්රොසොෆ්ට් විසින්ම එහි මොඩියුල ලියන අතර ඒවා මේ ආකාරයෙන් පරීක්ෂා කරයි. ඇත්ත වශයෙන්ම එය විවෘත මූලාශ්රයකි. මම කතා කරන හැම දෙයක්ම ඔයාට ඇවිත් හදාගන්න පුළුවන්. මට වාඩි වෙලා සතියකින් ඔක්කොම හදන්න පුළුවන්, open source VS code plugins, terraforms, rider එකට plugin එකක් හදන්න. සමහර විට විශ්ලේෂක කිහිපයක් ලියන්න, ලින්ටර් එකතු කරන්න, පරීක්ෂණ සඳහා පුස්තකාලයකට දායක වන්න. මට හැමදේම කරන්න පුළුවන්. නමුත් මා කළ යුත්තේ එය නොවේ.
හොඳම භාවිතයන් යටිතල පහසුකම් කේතය ලෙස
අපි ඉදිරියට යමු. IaC හි පරීක්ෂණ නොමැති නම්, IDE සහ සුසර කිරීම නරක නම්, අවම වශයෙන් හොඳම භාවිතයන් තිබිය යුතුය. මම Google Analytics වෙත ගොස් සෙවුම් විමසුම් දෙකක් සංසන්දනය කළෙමි: Terraform best practices සහ c# best practices.
අපි දකින්නේ කුමක්ද? නිර්දය සංඛ්‍යාලේඛන අපට වාසිදායක නොවේ. ද්රව්ය ප්රමාණය සමාන වේ. C# සංවර්ධනයේ දී, අපි හුදෙක් ද්‍රව්‍යවල ගිලී සිටිමු, අපට සුපිරි-හොඳ භාවිතයන් ඇත, ප්‍රවීණයන් විසින් ලියන ලද පොත් ඇත, එසේම එම පොත් විවේචනය කරන වෙනත් ප්‍රවීණයන්ගේ පොත් මත ලියා ඇති පොත් ද ඇත. නිල ලේඛන, ලිපි, පුහුණු පාඨමාලා සහ දැන් විවෘත මූලාශ්‍ර සංවර්ධනයේ මුහුදක්.
IaC ඉල්ලීම සම්බන්ධයෙන්: මෙහිදී ඔබ හයිලෝඩ් හෝ HashiConf වාර්තා, නිල ලේඛන සහ Github හි ගැටලු රාශියකින් තොරතුරු ටිකෙන් ටික රැස් කිරීමට උත්සාහ කරයි. සාමාන්යයෙන් මෙම මොඩියුල බෙදාහරින්නේ කෙසේද, ඔවුන් සමඟ කළ යුත්තේ කුමක්ද? මේක ඇත්තම ප්‍රශ්නයක් බව පේනවා... ප්‍රජාවක් ඉන්නවා මහත්තයෝ, ඕනම ප්‍රශ්නයකට Github එකේ කමෙන්ට් 10ක් දෙනවා. නමුත් එය හරියටම නොවේ.
අවාසනාවකට මෙන්, මෙම කාලය තුළ විශේෂඥයින් මතු වීමට පටන් ගෙන තිබේ. මේ වන විට ඒවායින් ස්වල්පයක් ඇත. තවද ප්‍රජාවම ප්‍රාථමික මට්ටමේ එල්ලෙමින් පවතී.
මේ සියල්ල යන්නේ කොහේද සහ කුමක් කළ යුතුද
ඔබට සියල්ල අතහැර C# වෙත ආපසු යා හැකිය, ධාවකයාගේ ලෝකයට. නමුත් නැහැ. ඔබට විසඳුමක් සොයාගත නොහැකි නම් ඔබ මෙය කිරීමට පවා කරදර වන්නේ ඇයි? පහතින් මම මගේ ආත්මීය නිගමන ඉදිරිපත් කරමි. අදහස් දැක්වීමේදී ඔබට මා සමඟ තර්ක කළ හැකිය, එය රසවත් වනු ඇත.
පුද්ගලිකව, මම කරුණු කිහිපයක් මත ඔට්ටු අල්ලමි:
- මේ ප්‍රදේශයේ සංවර්ධනය ඉතා ඉක්මනින් සිදුවෙනවා. DevOps සඳහා ඉල්ලීම් කාලසටහනක් මෙන්න.
මාතෘකාව උද්දීපනයක් විය හැකි නමුත්, ගෝලය වර්ධනය වෙමින් පවතින බව යම් බලාපොරොත්තුවක් ලබා දෙයි.යමක් මෙතරම් ඉක්මනින් වර්ධනය වුවහොත්, කළ යුතු දේ සහ නොකළ යුතු දේ ඔබට පවසන බුද්ධිමත් පුද්ගලයින් අනිවාර්යයෙන්ම පෙනී සිටිනු ඇත. ජනප්‍රියත්වය වැඩි වීම නිසා අවසානයේ jsonnet වෙත vcode සඳහා ප්ලගිනයක් එක් කිරීමට යමෙකුට කාලය ලැබෙනු ඇත, එය ctrl+shift+f හරහා එය සෙවීමට වඩා ශ්‍රිතය ක්‍රියාත්මක කිරීමට ඉදිරියට යාමට ඔබට ඉඩ සලසයි. දේවල් පරිණාමය වන විට, තවත් ද්රව්ය මතු වේ. SRE ගැන Google වෙතින් පොතක් නිකුත් කිරීම මෙයට කදිම නිදසුනකි.
- සාම්ප්‍රදායික සංවර්ධනයේ දියුණු තාක්ෂණික ක්‍රම සහ භාවිතයන් අපට මෙහි සාර්ථකව යෙදිය හැක. ඔව්, පරීක්ෂණ සහ විෂම පරිසරයක්, ප්‍රමාණවත් මෙවලම් නොමැති සූක්ෂ්මතා ඇත, නමුත් ප්රයෝජනවත් සහ ප්රයෝජනවත් විය හැකි භාවිතයන් විශාල ප්‍රමාණයක් එකතු වී ඇත.
සුළු උදාහරණයක්: යුගල වැඩසටහන්කරණය හරහා සහයෝගිතාව. එය තේරුම් ගැනීමට බොහෝ උපකාර කරයි. යමක් තේරුම් ගැනීමට උත්සාහ කරන අසල්වැසියෙකු ඔබ අසල සිටින විට, ඔබ එකට වඩා හොඳින් තේරුම් ගනීවි.
ප්‍රතිනිර්මාණය කරන්නේ කෙසේද යන්න තේරුම් ගැනීම එවැනි තත්වයක් තුළ පවා එය සිදු කිරීමට උපකාරී වේ. එනම්, ඔබට එකවර සියල්ල වෙනස් කළ නොහැක, නමුත් නම් කිරීම වෙනස් කරන්න, පසුව ස්ථානය වෙනස් කරන්න, එවිට ඔබට යම් කොටසක් ඉස්මතු කළ හැකිය, ඔහ්, නමුත් මෙහි ප්‍රමාණවත් අදහස් නොමැත.
නිගමනය
මගේ තර්කය අශුභවාදී බවක් පෙනෙන්නට තිබුණත්, මම අනාගතය දෙස බලාපොරොත්තුවෙන් බලා සිටින අතර සෑම දෙයක්ම අප (සහ ඔබ) වෙනුවෙන් සාර්ථක වනු ඇතැයි මම අවංකවම බලාපොරොත්තු වෙමි.
ලිපියේ දෙවන කොටස ඊළඟට සූදානම් වෙමින් පවතී. එහි දී, අපගේ ඉගෙනුම් ක්‍රියාවලිය වැඩිදියුණු කිරීමට සහ යටිතල පහසුකම් සමඟ වැඩ කිරීමට කඩිසර සංවර්ධන භාවිතයන් භාවිතා කිරීමට අප උත්සාහ කළ ආකාරය ගැන මම කතා කරමි.
මූලාශ්රය: www.habr.com