DevOpsDays മോസ്കോ കോൺഫറൻസിന്റെ അവലോകനം: 6 റിപ്പോർട്ടുകളിൽ നിന്നുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ

മൂന്നാം സമ്മേളനം ഡിസംബർ ഏഴിന് നടന്നു DevOpsDays മോസ്കോ, Mail.ru ക്ലൗഡ് സൊല്യൂഷൻസിന്റെ പിന്തുണയോടെ മോസ്കോ DevOps കമ്മ്യൂണിറ്റി സംഘടിപ്പിച്ചത്. പ്രമുഖ DevOps പ്രാക്ടീഷണർമാരുടെ അവതരണങ്ങൾക്ക് പുറമേ, പങ്കെടുക്കുന്നവർക്ക് ഹ്രസ്വ പ്രചോദിപ്പിക്കുന്ന മിന്നൽ സംഭാഷണങ്ങളിലും വർക്ക്ഷോപ്പുകളിലും തുറസ്സായ സ്ഥലങ്ങളിൽ ആശയവിനിമയം നടത്താനും കഴിയും.

ആറ് പ്രസംഗങ്ങളിൽ നിന്ന് ഞങ്ങൾ പ്രധാനപ്പെട്ട സ്ഥിതിവിവരക്കണക്കുകൾ ശേഖരിക്കുകയും റിപ്പോർട്ടുകൾക്ക് പിന്നിൽ എന്താണ് അവശേഷിക്കുന്നതെന്ന് കണ്ടെത്താൻ നിരവധി സ്പീക്കറുകളുമായി അഭിമുഖങ്ങൾ നടത്തുകയും ചെയ്തു.

അകത്ത്:

1. ബറൂച്ച് സഡോഗുർസ്‌കി, ജെഫ്രോഗ്: “സോഫ്റ്റ്‌വെയർ വെണ്ടറിൽ നിന്ന് ഉപയോക്താവിലേക്ക് ദ്രാവകം പോലെ ഒഴുകട്ടെ”
2. പാവൽ സെലിവാനോവ്, സൗത്ത്ബ്രിഡ്ജ്: "ഡെവിനും ഓപ്‌സിനും ഒരു പൊതു ചുമതലയുണ്ട് - പ്രവർത്തിക്കുന്ന ഒരു ഉൽപ്പന്നം നിർമ്മിക്കുക"
3. Vladimir Utratenko, X5 റീട്ടെയിൽ ഗ്രൂപ്പ്: "എന്റർപ്രൈസിലെ DevOps വേദനയും തീയും ഇല്ലാതെയുള്ള വികസനമാണ്"
4. സെർജി പുസിറെവ്, ഫേസ്ബുക്ക്: "പ്രൊഡക്ഷൻ എഞ്ചിനീയർ സേവനത്തെ മൊത്തത്തിൽ ശ്രദ്ധിക്കുന്നു: അതിനാൽ ഉപയോക്താക്കൾക്കും ഡവലപ്പർമാർക്കും നല്ല സമയം ലഭിക്കും"
5. മിഖായേൽ ചിങ്കോവ്, അംബോസ്: "ഒരു വകുപ്പിന് DevOps പാത പിന്തുടരാൻ കഴിയില്ല, മുഴുവൻ കമ്പനിയും അത് പിന്തുടരണം"
6. Rosbank-ന്റെ DevOps പ്രേമികൾ: "ഒരു രക്തരൂക്ഷിതമായ സംരംഭത്തിൽ DevOps നടപ്പിലാക്കാൻ 1000 ദിവസം"

1. ബറൂച്ച് സഡോഗുർസ്‌കി, ജെഫ്രോഗ്: “സോഫ്റ്റ്‌വെയർ വെണ്ടറിൽ നിന്ന് ഉപയോക്താവിലേക്ക് ദ്രാവകം പോലെ ഒഴുകട്ടെ”

സോഫ്റ്റ്‌വെയർ അപ്‌ഡേറ്റ് പരാജയങ്ങൾ ഓരോ മണിക്കൂറിലും എല്ലാവർക്കുമായി സംഭവിക്കുന്നു. പ്രസംഗത്തിൽ നിന്നുള്ള ഒരു ഹൊറർ സ്റ്റോറി ഇതാ: പരാജയപ്പെട്ട അപ്‌ഡേറ്റിന് ശേഷം ഒരു മണിക്കൂറിനുള്ളിൽ നൈറ്റ് ക്യാപിറ്റലിന് $440 മില്യൺ നഷ്ടമായി.

പരാജയങ്ങളും ഉപയോക്തൃ വിദ്വേഷവും ഒഴിവാക്കാൻ സഹായിക്കുന്ന തുടർച്ചയായ അപ്‌ഡേറ്റുകളുടെ DevOps പാറ്റേണുകളെ കുറിച്ച് ബറൂച്ച് സംസാരിച്ചു:

പ്രാദേശിക തിരിച്ചുവരവ് — എന്തെങ്കിലും സംഭവിച്ചാൽ തിരികെ കൊണ്ടുവരാൻ സോഫ്‌റ്റ്‌വെയറിന്റെ മുൻ പതിപ്പ് നിങ്ങളുടെ ഉപകരണത്തിൽ സൂക്ഷിക്കുക. നിങ്ങൾക്ക് വായുവിലൂടെ ഒരു പാച്ച് അയയ്‌ക്കാൻ കഴിയാത്തവിധം കാര്യങ്ങൾ മോശമായാൽ ഇത് നിങ്ങളെ സംരക്ഷിക്കും.

ഓവർ ദി എയർ അപ്‌ഡേറ്റുകൾ - മെച്ചപ്പെട്ട തുടർച്ചയായ. അല്ലാത്തപക്ഷം, ഇത് ജാഗ്വാർ ഡവലപ്പർമാരെപ്പോലെ ആയിരിക്കും: ബ്രേക്ക് സിസ്റ്റത്തിലെ ഒരു ബഗ് കാരണം, വായുവിൽ അപ്‌ഡേറ്റ് ചെയ്യാൻ കഴിയാത്തതിനാൽ, കാറുകൾ വിൽപ്പനയിൽ നിന്ന് തിരിച്ചുവിളിക്കേണ്ടി വന്നു. അത് വേദനാജനകവും ചെലവേറിയതുമായിരുന്നു.

തുടർച്ചയായ അപ്ഡേറ്റുകൾ — ഒരു പുതിയ ഫീച്ചർ തയ്യാറായാലുടൻ സോഫ്റ്റ്‌വെയർ തുടർച്ചയായി അപ്ഡേറ്റ് ചെയ്യുക. അപൂർവ അപ്‌ഡേറ്റുകൾക്കൊപ്പം, സവിശേഷതകൾ ഒരുമിച്ച് ഗ്രൂപ്പുചെയ്യുന്നു; ഒരു നിർണായക അപ്‌ഡേറ്റ് നിർണായകമല്ലാത്തവയ്ക്കായി കാത്തിരിക്കാം. ടെസ്‌ലയിലെ പോലെ, റാൻഡം ബ്രേക്കിംഗ് ശരിയാക്കേണ്ട ഒരു അപ്‌ഡേറ്റ് ചെസ്സ് ഗെയിമിലേക്കുള്ള ഒരു അപ്‌ഡേറ്റിനായി കാത്തിരിക്കുകയായിരുന്നു.

ഓട്ടോമേറ്റഡ് വിന്യാസം - ആളുകൾക്ക് പകരം യന്ത്രങ്ങൾ നൽകുക, കാരണം ആളുകൾ പതിവ് പ്രവർത്തനങ്ങൾ ചെയ്യുന്നതിൽ മോശമാണ്.

പതിവ് അപ്ഡേറ്റുകൾ - ഒരു ശീലം വികസിപ്പിക്കാനും ഭയത്തിൽ നിന്ന് മുക്തി നേടാനും നിങ്ങളെ സഹായിക്കുന്നു. അപൂർവമായ അപ്‌ഡേറ്റുകൾ അടിയന്തര ഇവന്റുകളായി മാറുന്നു.

ഉപകരണത്തിന്റെ അവസ്ഥ അറിയുന്നു — ടെസ്റ്റ് അപ്ഡേറ്റുകൾ, ആദ്യം മുതൽ ഇൻസ്റ്റലേഷൻ അല്ല. ഉപകരണത്തിന്റെ അവസ്ഥയെ ആശ്രയിച്ച് അപ്‌ഡേറ്റുകൾ വ്യത്യസ്തമായി പ്രവർത്തിച്ചേക്കാം എന്നതിനാൽ ഇത് പ്രധാനമാണ്.

കാനറി റിലീസ് ചെയ്യുന്നു — ഒരു ചെറിയ എണ്ണം ഉപയോക്താക്കൾക്ക് അപ്ഡേറ്റുകൾ പുറത്തിറക്കി നിരീക്ഷിക്കുക. എന്തെങ്കിലും തെറ്റ് സംഭവിച്ചാൽ ഇത് കേടുപാടുകൾ കുറയ്ക്കുന്നു.

ലഭ്യമല്ലാത്ത അപ്ഡേറ്റുകൾ — പുതിയ ഫീച്ചറുകൾ മാത്രം ശ്രദ്ധിക്കാൻ ഉപഭോക്താക്കളെ അനുവദിക്കുക, നിങ്ങൾ ഒരു അപ്‌ഡേറ്റ് പുറത്തിറക്കുമ്പോൾ ആഴ്ചകളോളം സേവനമില്ലാതെ തുടരരുത്.

റഷ്യൻ, വെസ്റ്റേൺ ഐടിയിൽ DevOps-ലെ കാഴ്ച എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു, ക്ലൗഡ് ഉടൻ തന്നെ ഞങ്ങൾക്കായി എല്ലാം ചെയ്യുമോ, എല്ലാ സോഫ്റ്റ്‌വെയർ സേവനങ്ങളും aaS സ്കീമിലേക്ക് സ്ലൈഡ് ചെയ്യുമോ എന്നതിനെക്കുറിച്ച് ഞങ്ങൾ ബറൂച്ച് സഡോഗുർസ്‌കിയുമായി സംസാരിച്ചു - അഭിമുഖം കാണുക:

2. പാവൽ സെലിവനോവ്, സൗത്ത്ബ്രിഡ്ജ്: "ഡെവിനും ഓപ്‌സിനും ഒരു പൊതു ചുമതലയുണ്ട് - പ്രവർത്തിക്കുന്ന ഒരു ഉൽപ്പന്നം നിർമ്മിക്കുക"

Kubernetes നടപ്പിലാക്കുന്നത് DevOps നേടാൻ സഹായിക്കില്ല, നേരെമറിച്ച്, അത് എല്ലാം തകർക്കും. സാങ്കേതികവിദ്യയ്ക്ക് (ഏറ്റവും മികച്ചത്) നിങ്ങളുടെ എല്ലാ പ്രശ്നങ്ങളും പരിഹരിക്കാൻ കഴിയാത്തത് എന്തുകൊണ്ടെന്ന് പവൽ വിശദീകരിച്ചു:

പദ്ധതിയുടെ സങ്കീർണ്ണത കോഡിനപ്പുറത്തേക്ക് നീങ്ങി. മുമ്പ്, ഒരു സങ്കീർണ്ണമായ ആപ്ലിക്കേഷൻ ഉണ്ടായിരുന്നു: പ്രോജക്റ്റിനുള്ളിലെ ഇടപെടലും സങ്കീർണ്ണമായ വികസനവും, എന്നാൽ ഒരു ലളിതമായ ഘടന - അഡ്മിനിസ്ട്രേറ്റർ അത് വിന്യസിച്ചു, എല്ലാം പ്രവർത്തിക്കുന്നു. ഞങ്ങൾ മൈക്രോസർവീസുകളിലേക്ക് നീങ്ങി: ഓരോ സേവനവും ഒരു ലളിതമായ ആപ്ലിക്കേഷനാണ്, സ്റ്റാൻഡേർഡ് പ്രോട്ടോക്കോളുകൾ ഉപയോഗിച്ചുള്ള ആശയവിനിമയവും ദ്രുതഗതിയിലുള്ള വികസനവും, എന്നാൽ പ്രോജക്റ്റ് ഘടന കൂടുതൽ സങ്കീർണ്ണമായിരിക്കുന്നു. മൈക്രോസർവീസ് ആർക്കിടെക്ചറുള്ള ഒരു പ്രോജക്റ്റിന്റെ സങ്കീർണ്ണത നീങ്ങിയിട്ടില്ല - അത് കോഡിനപ്പുറത്തേക്ക് നീങ്ങി. ഇപ്പോൾ അതിന്റെ ഉത്തരവാദിത്തം DevOps എഞ്ചിനീയർക്കാണ്.

DevOps നടപ്പിലാക്കിയതിന് ശേഷം ഡെവലപ്പർമാർക്ക് മാറ്റങ്ങൾ ആവശ്യമില്ല. തൽഫലമായി, കുബെർനെറ്റസിനൊപ്പമുള്ള വർക്ക് ഫ്ലോ ഒരു മതിലിനു മുകളിലൂടെ ദേവിൽ നിന്ന് ഓപ്‌സിലേക്ക് ടാസ്‌ക്കുകൾ എറിയുന്നത് പോലെ തുടരുന്നു, ഒരു രൂപകമല്ല - Git അത്തരമൊരു മതിലായി മാറുന്നു. ഡെവലപ്പർ അവിടെ കോഡ് ഇടുകയും മുമ്പത്തെപ്പോലെ പ്രവർത്തിക്കുകയും ചെയ്യുന്നു, കൂടാതെ അഡ്മിൻമാർക്ക് കുബർനെറ്റുകളും സിഐ/സിഡിയും മറ്റെല്ലാം ഉണ്ട്.

എന്നിരുന്നാലും, ഡെവലപ്പർമാർ മാറ്റങ്ങൾ അംഗീകരിക്കേണ്ടതുണ്ട്. അഡ്മിൻമാർ എന്താണ് ചെയ്യുന്നതെന്ന് ഡവലപ്പർമാർക്കും ഡെവലപ്പർമാർക്ക് എന്താണ് സംഭവിക്കുന്നതെന്ന് അഡ്മിൻമാർക്കും അറിയാത്ത സാഹചര്യം പ്രശ്നങ്ങൾ സൃഷ്ടിക്കുന്നു.

ഡവലപ്പർമാർക്കായി ഒന്നും മാറിയിട്ടില്ലെങ്കിൽ, ആപ്ലിക്കേഷന്റെ പ്രവർത്തനം അവരുടെ ഉത്തരവാദിത്തമാണെന്ന് അവർ മനസ്സിലാക്കുന്നില്ല - വിവിധ സാങ്കേതിക തന്ത്രങ്ങൾ പ്രവർത്തിക്കില്ല.

DevOps, Kubernetes എന്നിവയുടെ വരവോടെ, വികസനത്തിൽ വളരെയധികം മാറ്റമുണ്ടാകും. Devs Ops-ലും തിരിച്ചും കഴിവുള്ളവരായിരിക്കണം. ഈ സ്പെഷ്യലിസ്റ്റുകൾക്ക് അവരുടേതായ പ്രത്യേക കഴിവുകളുണ്ട്, എന്നാൽ അവർ പരസ്പരം ജോലിയെക്കുറിച്ച് അറിഞ്ഞിരിക്കണം. Kubernetes നടപ്പിലാക്കുന്നതിന് മുമ്പ് Dev ഉം Ops ഉം സുഹൃത്തുക്കളായിരിക്കണം, അല്ലാത്തപക്ഷം നിങ്ങളുടെ പക്കലുള്ളത് നിങ്ങൾ തകർക്കും.

5 വർഷത്തിനുള്ളിൽ കുബെർനെറ്റസിന് എന്ത് സംഭവിക്കുമെന്നും ഒരു ആധുനിക സ്റ്റാർട്ടപ്പ് ഒരു ടെക്നോളജി സ്റ്റാക്ക് നിർമ്മിക്കുന്നതിനെക്കുറിച്ചും പവൽ സെലിവാനോവ് സംസാരിച്ചു - അഭിമുഖം കാണുക:

3. Vladimir Utratenko, X5 റീട്ടെയിൽ ഗ്രൂപ്പ്: "എന്റർപ്രൈസിലെ DevOps വേദനയും തീയും ഇല്ലാതെയുള്ള വികസനമാണ്"

വികസനം വളരെ മന്ദഗതിയിലാണെന്നും യാഥാർത്ഥ്യങ്ങളുമായി പൊരുത്തപ്പെടുന്നില്ലെന്നും മനസ്സിലാക്കുമ്പോഴാണ് കമ്പനികൾ DevOps പരിവർത്തനത്തിലേക്ക് വരുന്നത്, അവർക്ക് മികച്ച രീതിയിൽ വികസിപ്പിക്കാനും വേഗത്തിൽ വികസിക്കാനുമുള്ള ആഗ്രഹമുണ്ട്.

ഇത് എങ്ങനെ സംഭവിക്കുന്നുവെന്നും ക്യാച്ച് എന്താണെന്നും വ്‌ളാഡിമിർ വിശദീകരിച്ചു:

1. ആദ്യം, കമ്പനികൾ ഒരു DevOps എഞ്ചിനീയറെ നിയമിക്കുന്നു. ഇതൊരു സീനിയർ സിസ്റ്റം അഡ്‌മിനിസ്‌ട്രേറ്ററാണ്, പ്രൊഡക്ഷനിലേക്ക് ഒരു റിലീസ് വിന്യസിക്കുക, വികസന അന്തരീക്ഷം സ്റ്റാൻഡേർഡ് ചെയ്യുക, ഇൻഫ്രാസ്ട്രക്ചർ സജ്ജീകരിക്കുക, വിവിധ പ്രശ്നങ്ങൾ കണ്ടെത്തുകയും പരിഹരിക്കുകയും ചെയ്യുക, പ്രക്രിയകൾ ഓട്ടോമേറ്റ് ചെയ്യുക, മറ്റ് സാങ്കേതിക ജോലികൾ എന്നിവയിൽ അദ്ദേഹം ഏർപ്പെട്ടിരിക്കുന്നു.
2. അപ്പോൾ ഒരു DevOps എഞ്ചിനീയർ മതിയാകില്ല, കമ്പനി ഒരു DevOps ടീമിനെ നിയമിക്കുന്നു. വ്യത്യസ്‌തരായ എഞ്ചിനീയർമാരുടെ ശ്രമങ്ങൾ സംഘടിപ്പിക്കുകയും അവരെ ഒരു ദിശയിൽ കേന്ദ്രീകരിക്കാൻ അനുവദിക്കുകയും ചെയ്യുന്ന ഒരു യോഗ്യതാ കേന്ദ്രമാണിത്.
3. വാസ്തവത്തിൽ, DevOps എഞ്ചിനീയറും DevOps ടീമുകളും DevOps പരിവർത്തനത്തിന്റെ വിരുദ്ധ പാറ്റേണുകളാണ്. DevOps സമ്പ്രദായങ്ങളെയും സംസ്കാരത്തെയും കുറിച്ചുള്ളതിനാൽ, കൂടാതെ, സാങ്കേതിക കമ്പനികളിൽ (SRE, പ്രൊഡക്ഷൻ എഞ്ചിനീയറിംഗ്) DevOps നടപ്പിലാക്കുന്നു.

എന്തുചെയ്യും? DevOps പരിവർത്തനം നടപ്പിലാക്കുന്നതിനും പരിശീലനങ്ങൾ നടപ്പിലാക്കുന്നതിനും ഒരു വികസന സംസ്കാരവും സാങ്കേതിക സംസ്കാരവും വളർത്തിയെടുക്കാൻ സഹായിക്കുന്ന ഒരു താൽക്കാലിക DevOps ടീമിനെ നിയമിക്കുക.

ഒരു ബിസിനസ്സ് പ്രവർത്തനക്ഷമമാകുകയും DevOps-ൽ നിക്ഷേപിക്കുകയും ചെയ്യുമ്പോൾ, നിരവധി സാഹചര്യങ്ങൾ സാധ്യമാണ്: ടേക്ക് ഓഫ് ചെയ്യുമ്പോൾ എല്ലാം തകരും; എസ്ആർഇ/പ്രൊഡക്ഷൻ എഞ്ചിനീയറിംഗ് അല്ലെങ്കിൽ എംബഡഡ് ഓപ്‌സ് ആയി തുടരും; പ്രക്രിയകൾ ബിസിനസ് മെട്രിക്‌സിനെ അടിസ്ഥാനമാക്കിയുള്ളതായിരിക്കുമ്പോൾ, BizOps-ലേക്ക് നീങ്ങും.

ഒരു എന്റർപ്രൈസിലെ DevOps യഥാർത്ഥത്തിൽ എത്രമാത്രം "രക്തരൂക്ഷിതമായ" ആണെന്നും വലിയ റീട്ടെയിലിനുള്ളിൽ എങ്ങനെ പ്രാക്ടീസ് നടപ്പിലാക്കുന്നു എന്നതിനെക്കുറിച്ചും Vladimir Utratenko ഞങ്ങളോട് പറഞ്ഞു - അഭിമുഖം കാണുക:

4. സെർജി പുസിരെവ്, ഫേസ്ബുക്ക്: "പ്രൊഡക്ഷൻ എഞ്ചിനീയർ സേവനത്തെ മൊത്തത്തിൽ ശ്രദ്ധിക്കുന്നു: അതിനാൽ ഉപയോക്താക്കൾക്കും ഡവലപ്പർമാർക്കും നല്ല സമയം ലഭിക്കും"

ധാരാളം ഘടകങ്ങൾ, സെർവറുകൾ, ആളുകൾ, ഡാറ്റാ സെന്ററുകൾ എന്നിവയുള്ള ഒരു വലിയ കമ്പനിയാണ് Facebook. വലിയ വലിപ്പം ഉണ്ടായിരുന്നിട്ടും, ഇത് വളരെ വേഗതയുള്ളതാണ് - ഡവലപ്പർമാർക്ക് ദിവസത്തിൽ പല തവണ സേവനങ്ങൾ പുറത്തിറക്കാൻ കഴിയും. കൂടാതെ, Facebook അതിവേഗം വളരുകയാണ്, മാത്രമല്ല ഉപയോക്താക്കളുടെയും സെർവറുകളുടെയും എണ്ണം മാത്രമല്ല, ഡെവലപ്പർമാരുടെ എണ്ണവും വർദ്ധിക്കുന്നു, ഇത് പ്രക്രിയകളെ കൂടുതൽ സങ്കീർണ്ണമാക്കുന്നു.

ഒരു പ്രൊഡക്ഷൻ എഞ്ചിനീയർ ഫേസ്ബുക്കിൽ എന്താണ് ചെയ്യുന്നതെന്ന് സെർജി പറഞ്ഞു:

1. ഒരു പ്രൊഡക്ഷൻ എഞ്ചിനീയർ ധാരാളം കോഡുകൾ ചെയ്യുന്നു, അയാൾക്ക് സിസ്റ്റം പരിജ്ഞാനം ഉണ്ടായിരിക്കണം: ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങൾ, ഫയൽ സിസ്റ്റങ്ങൾ, ഡാറ്റാബേസുകൾ, നെറ്റ്‌വർക്കുകൾ തുടങ്ങിയവ. ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റങ്ങളിലും റിലയബിലിറ്റി എഞ്ചിനീയറിംഗിലും പ്രവർത്തിച്ച പരിചയം ഉണ്ടായിരിക്കണം, അതായത് ഉൽപ്പന്ന വിശ്വാസ്യതയെ പിന്തുണയ്ക്കുന്നു. ഇത് ഓൺ-കോൾ ആയിരിക്കണം, അതായത്, എപ്പോൾ വേണമെങ്കിലും വിളിക്കാൻ ലഭ്യമാണ്.
2. പ്രൊഡക്ഷൻ എഞ്ചിനീയർ സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറിൽ നിന്ന് വ്യത്യസ്തമാണ്, പ്രവർത്തനത്തിൽ വിപുലമായ വൈദഗ്ദ്ധ്യം ഉണ്ട്, എന്നാൽ വാസ്തവത്തിൽ, സോഫ്റ്റ്വെയർ എഞ്ചിനീയറുടെ ഒരു ഉപജാതിയാണ്. സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയർമാർ കൂടുതൽ കോഡ് ചെയ്യുന്നു; അവർക്ക് ഡാറ്റ പ്രോസസ്സിംഗുമായി ബന്ധപ്പെട്ട അധിക കഴിവുകൾ ഉണ്ടായിരിക്കാം. ഫേസ്ബുക്കിൽ, അത്തരം സ്പെഷ്യലിസ്റ്റുകളും ഓൺ-കോൾ ആയിരിക്കണം, ഇത് പലർക്കും അസുഖകരമായ ആശ്ചര്യമാണ്.
3. ഒരു കമ്പനിയിലെ പ്രൊഡക്ഷൻ എഞ്ചിനീയറുടെ ആവശ്യകതകളുടെ പിരമിഡ് ആരംഭിക്കുന്നത് സെർവറുകളും അവയുടെ ജീവിത ചക്രവും നിരീക്ഷിക്കുന്നതിലൂടെയാണ്, അതായത്, പുതിയ ഹാർഡ്‌വെയർ നേടുക, അത് സജ്ജീകരിക്കുക, പ്രവർത്തനക്ഷമമാക്കുക. അടുത്ത ലെവൽ സേവന തലത്തിലും സമാനമാണ്: നിരീക്ഷണ സേവനങ്ങളും അവയുടെ ജീവിത ചക്രവും. തുടർന്ന് തടസ്സമില്ലാത്ത സ്കെയിലിംഗും വിപുലമായ നിരീക്ഷണവും വരുന്നു. സേവന ജീവിത ചക്രം യാന്ത്രികമാക്കിയ ശേഷം അവർ ഓട്ടോസ്‌കേലിംഗിലേക്ക് മാറുന്നു. അവസാനം, ട്യൂണിംഗ് നടത്തേണ്ടത് ആവശ്യമാണ്, അതുവഴി സ്കെയിലിംഗ് ഫലപ്രദമാകുകയും കമ്പനി പണവും വിഭവങ്ങളും ലാഭിക്കുകയും ചെയ്യുന്നു.

5. മിഖായേൽ ചിങ്കോവ്, അംബോസ്: "ഒരു വകുപ്പിന് DevOps പാത പിന്തുടരാൻ കഴിയില്ല, മുഴുവൻ കമ്പനിയും അത് പിന്തുടരണം"

DevOps തുടർച്ചയായ വികസനമാണെന്ന് മിഖായേൽ വിശ്വസിക്കുന്നു. നിങ്ങൾക്ക് ചില ഉപകരണങ്ങൾ പരിചയപ്പെടുത്തി അവിടെ നിർത്താൻ കഴിയില്ല. DevOps ആകുന്നതിൽ നിന്ന് കമ്പനികളെ തടയുന്ന പ്രശ്‌നങ്ങൾ എന്തൊക്കെയാണ്, എങ്ങനെ രീതികൾ നടപ്പിലാക്കാം?

DevOps മനസ്സിലാക്കുന്നതിലെ വ്യത്യാസം. കാനോനിക്കൽ ഡെവോപ്പുകൾ, സുവിശേഷകർ കാണുന്നതുപോലെ, 5 തൂണുകളിൽ നിലകൊള്ളുന്നു:

• സംസ്കാരം - ആളുകളിലും സഹകരണത്തിലും ശ്രദ്ധ കേന്ദ്രീകരിക്കുക;
• ഓട്ടോമേഷൻ - വർക്ക്ഫ്ലോയിലേക്കുള്ള പതിവ് ഡെലിഗേഷൻ;
• മെലിഞ്ഞ - ഉപയോക്താവിന് മൂല്യം നൽകുന്നതിൽ ഊന്നൽ;
• പങ്കിടൽ - അറിവിന്റെ തുടർച്ചയായ കൈമാറ്റം;
• അളവുകളും അവ ഉപയോഗിച്ച് ഫീഡ്ബാക്ക് സ്വീകരിക്കലും.

കമ്പനികൾ സാധാരണയായി ഓട്ടോമേഷനിലും ഉപയോക്താവിന് മൂല്യം എത്തിക്കുന്നതിലും മാത്രമാണ് ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത്. എന്നാൽ സംസ്കാരം, അറിവ് പങ്കിടൽ, വികസനം ട്രാക്ക് ചെയ്യുന്നതിനുള്ള DevOps അളവുകൾ എന്നിവ പശ്ചാത്തലത്തിലേക്ക് മങ്ങുന്നു.

DevOps സ്റ്റാൻഡേർഡൈസേഷൻ വെല്ലുവിളികൾ. ഉൽപ്പന്ന ലക്ഷ്യങ്ങൾ എല്ലാ കമ്പനികൾക്കും വ്യത്യസ്തമാണ്, അത് സ്റ്റാൻഡേർഡ് ചെയ്യാൻ കഴിയില്ല. ഒരു കമ്പനിയിലെ DevOps-ന്റെ അവസ്ഥ കമ്പനിയെ തന്നെ ആശ്രയിച്ചിരിക്കുന്നു, എന്നാൽ പലരും ഇത് മനസ്സിലാക്കുന്നില്ല, ഒരു DevOps എഞ്ചിനീയറെ നിയമിച്ചാൽ മതിയെന്ന് വിശ്വസിക്കുന്നു.

എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഇതുവരെ DevOps അല്ലാത്തത്? രണ്ട് പ്രധാന പ്രശ്നങ്ങളുണ്ട്. എന്റർപ്രൈസസിൽ ഓർഗനൈസേഷന്റെ മന്ദഗതിയിലുള്ള വികസനം ഉണ്ട്, ആയിരക്കണക്കിന് ജീവനക്കാരുടെ മനസ്സിൽ വെക്റ്റർ മാറ്റുന്നതിനുള്ള ബുദ്ധിമുട്ടുകൾ. സ്റ്റാർട്ടപ്പുകളിൽ, അറിവിന്റെ സ്രോതസ്സുകളുടെ അഭാവവും പരിവർത്തനത്തിനായി വിഭവങ്ങൾ അനുവദിക്കുന്നതിൽ പ്രശ്‌നവുമുണ്ട്.

ഒരു കമ്പനിയിലെ DevOps വികസനത്തിന്റെ ഘട്ടങ്ങൾ:

• ആദ്യത്തേത് ക്ലൗഡിലെ ഇൻഫ്രാസ്ട്രക്ചറാണ്, എന്നാൽ ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ഒന്നോ രണ്ടോ അഡ്‌മിനുകൾക്കല്ലാതെ ആർക്കും അറിയില്ല;
• രണ്ടാമതായി, ഇൻഫ്രാസ്ട്രക്ചർ എല്ലാ എഞ്ചിനീയർമാർക്കും സുതാര്യവും മനസ്സിലാക്കാവുന്നതുമാണ്, എന്നാൽ പ്രക്രിയകൾ കാര്യക്ഷമമല്ല;
• മൂന്നാമത് - എഞ്ചിനീയർമാർ സ്വതന്ത്രമായി തത്സമയ സേവനങ്ങൾ സമാരംഭിക്കുകയും നന്നാക്കുകയും ചെയ്യുന്നു;
• നാലാമത്തേത് - എഞ്ചിനീയർമാർ കോർ ഇൻഫ്രാസ്ട്രക്ചർ, ക്ലൗഡിലെ സുതാര്യമായ കോഡ്, ബട്ടൺ ബൈ വിന്യാസം എന്നിവയ്ക്ക് ഓപ്ഷണലായി സംഭാവന ചെയ്യും.

അടിസ്ഥാന സൗകര്യങ്ങളിലേക്ക് എല്ലാവർക്കും ഒരേ പ്രവേശനമുണ്ട്, എല്ലാ എഞ്ചിനീയർമാർക്കും ഉൽപ്പന്നത്തിലേക്ക് പ്രവേശനമുണ്ട്, അവർ എന്താണ് ചെയ്യുന്നതെന്ന് മനസ്സിലാക്കുക എന്നതാണ് അനുയോജ്യമായ പദ്ധതി.

എല്ലാ സാംസ്കാരികവും സാങ്കേതികവുമായ ഗസ്റ്റാൾട്ടുകൾ അടച്ചുകഴിഞ്ഞാൽ, കമ്പനിയുടെ DevOps പരിവർത്തനം ബിസിനസ്സ്, പ്ലാറ്റ്‌ഫോം മെട്രിക്‌സിൽ നിന്നുള്ള ഫീഡ്‌ബാക്ക് കണക്കിലെടുക്കും.

6. Rosbank-ന്റെ DevOps പ്രേമികൾ: "രക്തരൂക്ഷിതമായ ഒരു സംരംഭത്തിൽ DevOps നടപ്പിലാക്കാൻ 1000 ദിവസം"

റോസ്ബാങ്കിൽ നിന്നുള്ള യൂറി ബുലിച്ച്, ദിന മാൽറ്റ്സേവ, എവ്ജെനി പാങ്കോവ് എന്നിവർ എങ്ങനെയാണ് മൂന്ന് വർഷത്തിനുള്ളിൽ DevOps-ൽ എത്തിയതെന്ന് പറഞ്ഞു. രണ്ട് ലക്ഷ്യങ്ങളുണ്ടായിരുന്നു: നിർദ്ദിഷ്ട ടീമുകളിലെ പ്രത്യേക പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനും കേന്ദ്രീകൃത ഉപകരണങ്ങൾ നടപ്പിലാക്കുന്നതിനും.

നേടിയ ഫലങ്ങൾ ഇതാ:

ഉൽപ്പന്ന ടീമുകൾക്കുള്ള ഫലങ്ങൾ: 30 മടങ്ങ് വേഗത്തിലുള്ള അസംബ്ലി, 6 മടങ്ങ് വേഗത്തിലുള്ള ഇൻസ്റ്റാളേഷൻ, പൂർണ്ണ സൈക്കിളിൽ 30% വരെ സേവിംഗ്സ്. ഉൽപ്പാദനക്ഷമതയിലേക്ക് പോകാൻ ഞങ്ങൾക്ക് ഇപ്പോൾ ഒരു ബട്ടൺ അമർത്താനുള്ള കഴിവുണ്ട്

പ്ലാറ്റ്ഫോം കമാൻഡുകൾക്കുള്ള ഫലങ്ങൾ: 10 മടങ്ങ് വേഗത്തിലുള്ള അസംബ്ലിയും ഇൻസ്റ്റാളേഷനും, 87% വർദ്ധിച്ച ഇൻസ്റ്റാളേഷനുകൾ, 46% ഓട്ടോടെസ്റ്റ് കവറേജ്. ഇന്റഗ്രേഷൻ ടീം ഇപ്പോൾ ഒരു തടസ്സമല്ല

അപ്പോൾ, രക്തരൂക്ഷിതമായ ഒരു സംരംഭത്തിൽ DevOps രീതികൾ എങ്ങനെ നടപ്പിലാക്കാം?

ആദ്യം ഒരു പൈലറ്റ് പദ്ധതി നടപ്പിലാക്കുക: ടീമുകളെ തിരഞ്ഞെടുക്കുക, ആർക്കിടെക്ചർ എങ്ങനെ നടപ്പിലാക്കണമെന്ന് തീരുമാനിക്കുക, ടൂളുകൾ തിരഞ്ഞെടുക്കുക. ബാങ്കിലെ ഇൻസ്റ്റാളേഷനും അവരോടൊപ്പം പ്രവർത്തിക്കാനുള്ള വൈദഗ്ധ്യവും ഉള്ള ഓപ്പൺ ലൈസൻസുള്ള ടൂളുകൾ ഞങ്ങൾ തിരഞ്ഞെടുത്തു. DevOps പ്ലാറ്റ്‌ഫോമിനൊപ്പം Rosbank ഒരേസമയം ഒരു സ്വകാര്യ ക്ലൗഡ് വിന്യസിച്ചു, ഇത് തുടക്കത്തിൽ സഹായിച്ചു. ക്ലൗഡിൽ, 15 മിനിറ്റിനുള്ളിൽ ഒരു ബട്ടണിന്റെ സ്പർശനത്തിൽ ആവശ്യമായ ഉറവിടങ്ങൾ നേടാനാകും; മുമ്പ്, അത്തരമൊരു പ്രക്രിയയ്ക്ക് ഒരാഴ്ച എടുത്തേക്കാം.

ബാങ്കുകളിലും മറ്റ് എന്റർപ്രൈസസുകളിലും, ഇൻഫർമേഷൻ സെക്യൂരിറ്റി ടീമുമായി മുൻകൂർ നിയന്ത്രണങ്ങൾ പ്രവർത്തിക്കുകയും മാറ്റങ്ങൾ നടപ്പിലാക്കാൻ അനുവദിക്കുന്ന ഒരു പരിഹാരം കണ്ടെത്തുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്.

പൈലറ്റിന് ശേഷം, വിജയകരമായ ഒരു പരിഹാരം സ്കെയിൽ ചെയ്യേണ്ടതുണ്ട്.

1. പൈപ്പ്ലൈൻ കഴിയുന്നത്ര "നേരെയാക്കാൻ" പ്രധാനമാണ്, അതിൽ നിന്ന് അനാവശ്യമായ ലിങ്കുകൾ ഒഴിവാക്കുക, മൂല്യ ദാതാക്കളെ ഹൈലൈറ്റ് ചെയ്യുക, ശേഷിക്കുന്ന ഘടകങ്ങൾ നീക്കം ചെയ്യുക. ഇന്റർമീഡിയറ്റുകൾ ആന്റിപാറ്റേണുകളാണ്. ഉദാഹരണത്തിന്, റോസ്ബാങ്കിൽ, നിരവധി ടീമുകൾ ആന്തരിക വികസനം വികസിപ്പിച്ചില്ല, ബാഹ്യ വികസനം മാത്രം അവശേഷിപ്പിച്ചു. ഇത് ഒരു സമർപ്പിത DevOps ടീമിന്റെ ആവിർഭാവത്തിലേക്ക് നയിച്ചു, ഇത് ബാഹ്യത്തിൽ നിന്ന് ആന്തരിക ഡെവലപ്പർമാർക്ക് കോഡ് കൈമാറുന്നത് ഉറപ്പാക്കുന്നു. ബാഹ്യ വികസനം CI/CD-യിലേക്ക് സംയോജിപ്പിച്ച് പ്രശ്നം പരിഹരിച്ചു, അതിലൂടെ അവർ കോഡ് അവരിൽ നിന്ന് ബാങ്കിലേക്ക് മാറ്റുക മാത്രമല്ല, അതിന്റെ വിജയത്തിന് ഉത്തരവാദികളായിരിക്കുകയും ചെയ്യും.
2. മെച്യൂരിറ്റി മോഡലിൽ DevOps പ്രാക്ടീസുകളുടെ ഘടകങ്ങൾ, ലിസ്റ്റ് ചെയ്ത ടൂളുകൾ എന്നിവ ഉൾപ്പെടുന്നു, കൂടാതെ ബാഹ്യ വിതരണക്കാരുമായി പ്രവർത്തിക്കുന്നതിന്റെ സവിശേഷതകൾ കണക്കിലെടുക്കുന്നു - ഭാവിയിൽ, പുതിയ ടീമുകളിൽ ടാസ്‌ക്കുകൾ നടപ്പിലാക്കുമ്പോൾ ബാക്ക്‌ലോഗ് വേഗത്തിൽ കുറയ്ക്കാൻ ഇത് സഹായിച്ചു.
3. മൃദുനിയന്ത്രണത്തിന്റെയും ശുപാർശകളുടെയും രൂപത്തിൽ നമുക്ക് ഭരണം ആവശ്യമാണ്. നന്നായി പ്രവർത്തിക്കുന്ന ഒരു DevOps ഹാൻഡ്‌ബുക്ക്, പ്ലാറ്റ്‌ഫോം ശരിയായി ഉപയോഗിക്കാൻ ടീമുകളെ സഹായിക്കുന്ന ഓർഗനൈസേഷണൽ, ടൂളിംഗ് സവിശേഷതകളുടെ ഒരു കൂട്ടമാണ്.
4. നിങ്ങൾ ഉടനടി സംസ്കാരത്തിൽ ശ്രദ്ധിക്കണം, അപ്പോൾ പല മാറ്റങ്ങളും വേഗത്തിലും എളുപ്പത്തിലും സംഭവിക്കും. നിങ്ങളുടെ ആന്തരിക കമ്മ്യൂണിറ്റി വളർത്തുക, മീറ്റപ്പുകൾ, സാങ്കേതിക ശിൽപശാലകൾ, പരിശീലനങ്ങൾ, രസകരമായ പ്രവർത്തനങ്ങൾ എന്നിവ നടത്തുക. ഇത് ഫലം കായ്ക്കുന്നു: ആളുകൾ സമ്പ്രദായങ്ങൾ പങ്കിടുന്നു, ആരാണ് എന്താണ് ചെയ്തതെന്ന് കാണുക, എവിടേക്ക് തിരിയണമെന്ന് അറിയുക, കമ്പനിക്കുള്ളിൽ ആവേശവും ആരോഗ്യകരമായ മത്സരവുമുണ്ട്.
5. പ്രക്രിയയിൽ ഉൾപ്പെടാത്തവരുമായി, പക്വത പ്രാപിക്കാത്ത ടീമുകളുമായി പ്രവർത്തിക്കുന്നതിൽ അർത്ഥമില്ല; താൽപ്പര്യമുള്ള ടീമുകളിലും വിശ്വസ്തരായ ആളുകളിലും നിക്ഷേപിക്കുന്നതാണ് നല്ലത്.
6. തിരഞ്ഞെടുത്ത പരിഹാരം അത് ഉപയോഗിക്കുന്ന എഞ്ചിനീയർമാർക്ക് സൗകര്യപ്രദമായിരിക്കണം.
7. ബാഹ്യ വികസനം ഒരു ബ്ലോക്കറല്ല; പരിശീലനങ്ങളും അവിടെ നടപ്പിലാക്കാൻ കഴിയും, പ്രധാന കാര്യം ടീമിന് തന്നെ ആഗ്രഹമുണ്ട് എന്നതാണ്.

കുറച്ചുകൂടി പ്രയോജനം

Alexander Chistyakov, vdsina.ru-ൽ നിന്നുള്ള DevOps-ൽ ഉള്ളവർക്ക് വായിക്കേണ്ട പുസ്തകങ്ങളുടെ ലിസ്റ്റ്:

1. ഐറിന യാകുട്ടെങ്കോ "ഇച്ഛയും ആത്മനിയന്ത്രണവും."
2. ഡാനിയൽ കാനെമാൻ "ചിന്തിക്കുന്നതും വേഗതയുള്ളതും മന്ദഗതിയിലുള്ളതും".
3. ബാർബറ ഓക്ക്ലി "എ മൈൻഡ് ഫോർ അക്കങ്ങൾ".
4. മാക്സിം ഡോറോഫീവ് "ജെഡി ടെക്നിക്കുകൾ".
5. വിക്ടർ ഫ്രാങ്ക്ൾ "മനുഷ്യന്റെ അർത്ഥത്തിനായുള്ള തിരയൽ".

ഇവിടെത്തന്നെ നിൽക്കുക

DevOps ഞങ്ങൾക്കും ഇഷ്ടമാണ്. പരമ്പര അറിയിപ്പുകൾ പിന്തുടരുക @DevOps കൂടാതെ @Kubernetes, അതുപോലെ മറ്റ് Mail.ru ക്ലൗഡ് സൊല്യൂഷൻസ് ഇവന്റുകൾ, ഞങ്ങളുടെ ടെലിഗ്രാം ചാനലിൽ: t.me/k8s_mail

അവലംബം: www.habr.com