DevOpsForum 2019. DevOps നടപ്പിലാക്കാൻ നിങ്ങൾക്ക് കാത്തിരിക്കാനാവില്ല

ലോഗ്രോകോൺ ഹോസ്റ്റ് ചെയ്ത DevOpsForum 2019-ൽ ഞാൻ അടുത്തിടെ പങ്കെടുത്തു. ഈ കോൺഫറൻസിൽ, പങ്കാളികൾ ബിസിനസും വികസനവും ഇൻഫർമേഷൻ ടെക്നോളജി സേവന വിദഗ്ധരും തമ്മിലുള്ള ഫലപ്രദമായ ഇടപെടലിന് പരിഹാരങ്ങളും പുതിയ ഉപകരണങ്ങളും കണ്ടെത്താൻ ശ്രമിച്ചു.

സമ്മേളനം വിജയകരമായിരുന്നു: ശരിക്കും ധാരാളം ഉപയോഗപ്രദമായ റിപ്പോർട്ടുകൾ, രസകരമായ അവതരണ ഫോർമാറ്റുകൾ, സ്പീക്കറുമായി ധാരാളം ആശയവിനിമയം എന്നിവ ഉണ്ടായിരുന്നു. വലിയ കോൺഫറൻസുകളിൽ സംസാരിക്കുന്നവർ ഈയിടെയായി കുറ്റക്കാരായ എന്തെങ്കിലും എനിക്ക് വിൽക്കാൻ ആരും ശ്രമിച്ചില്ല എന്നത് വളരെ പ്രധാനമാണ്.

Raiffeisenbank, Alfastrakhovanie എന്നിവരുടെ പ്രസംഗങ്ങളിൽ നിന്നുള്ള ഒരു ഉദ്ധരണി, ഓട്ടോമേഷനും മറ്റ് വിശദാംശങ്ങളും നടപ്പിലാക്കുന്നതിൽ മാംഗോ ടെലികോമിന്റെ അനുഭവം.

എന്റെ പേര് യാന, ഞാൻ ഒരു ടെസ്റ്ററായി ജോലി ചെയ്യുന്നു, ഞാൻ ഓട്ടോമേഷൻ ചെയ്യുന്നു, അതുപോലെ DevOps ചെയ്യുന്നു, കോൺഫറൻസുകളിലും മീറ്റ്അപ്പുകളിലും പോകുന്നത് എനിക്ക് ഇഷ്ടമാണ്. കഴിഞ്ഞ രണ്ട് വർഷമായി, ഞാൻ ഒലെഗ് ബുനിന്റെ കോൺഫറൻസുകളിൽ (ഹൈലോഡ്++, ടീംലീഡ് കോൺഫ്), ജഗ് ഇവന്റുകൾ (ഹെയ്‌സൻബഗ്, ജെപോയിന്റ്), ടെസ്റ്റ്‌കോൺ മോസ്കോ, ഡെവോപ്‌സ് പ്രോ മോസ്കോ, ബിഗ് ഡാറ്റ മോസ്കോ എന്നിവയിൽ പോയിട്ടുണ്ട്.

ഒന്നാമതായി, ഞാൻ കോൺഫറൻസ് പ്രോഗ്രാമിലേക്ക് ശ്രദ്ധ ആകർഷിക്കുന്നു. റിപ്പോർട്ട് എന്തിനെക്കുറിച്ചായിരിക്കുമെന്ന് ഞാൻ കുറച്ച് നോക്കുന്നു, സ്പീക്കറിലേക്ക് കൂടുതൽ. റിപ്പോർട്ട് വളരെ സാങ്കേതികവും രസകരവുമാണെന്ന് തെളിഞ്ഞാൽപ്പോലും, നിങ്ങളുടെ കമ്പനിയിലെ റിപ്പോർട്ടിൽ നിന്നുള്ള ചില മികച്ച സമ്പ്രദായങ്ങൾ നിങ്ങൾക്ക് പ്രയോഗിക്കാൻ കഴിയുമെന്നത് ഒരു വസ്തുതയല്ല. പിന്നെ ഒരു സ്പീക്കർ വേണം.

റൈഫിസെൻബാങ്കിലെ പൈപ്പ്ലൈനിന്റെ അറ്റത്ത് വെളിച്ചം

സാധാരണയായി, എനിക്ക് താൽപ്പര്യമുള്ള വശങ്ങളിൽ ഞാൻ സ്പീക്കറുകൾക്കായി വേട്ടയാടുന്നു. DevOpsForum 2019-ൽ, Raiffeisenbank-ൽ നിന്നുള്ള ഒരു സ്പീക്കർ, Mikhail Bizhan, എന്റെ താൽപ്പര്യം ആകർഷിച്ചു. തന്റെ പ്രസംഗത്തിനിടയിൽ, അവർ എങ്ങനെയാണ് അവരുടെ ടീമുകളെ DevOps-ൽ ക്രമേണ ആകർഷിക്കുന്നതെന്നും അവർക്ക് എന്തുകൊണ്ട് ഇത് ആവശ്യമാണ്, DevOps പരിവർത്തനം എന്ന ആശയം ബിസിനസ്സിലേക്ക് എങ്ങനെ വിൽക്കാമെന്നും അദ്ദേഹം സംസാരിച്ചു. ശരി, പൊതുവേ, പൈപ്പ്ലൈനിന്റെ അവസാനത്തിൽ വെളിച്ചം എങ്ങനെ കാണാമെന്ന് ഞാൻ സംസാരിച്ചു.

മിഖായേൽ ബിഷാൻ, റൈഫിസെൻബാങ്കിലെ ഓട്ടോമേഷൻ ഡയറക്ടർ

ഇപ്പോൾ അവരുടെ കമ്പനിയിൽ "DevOps" ഇല്ല. അതായത്, അവൻ പ്രവർത്തിക്കുന്നു, പക്ഷേ എല്ലാ ടീമുകളിലും അല്ല. DevOps നടപ്പിലാക്കുമ്പോൾ, നിർദ്ദിഷ്ട എഞ്ചിനീയർമാരുടെ കാര്യത്തിലും ഉൽപ്പന്നത്തിന്റെ ആവശ്യകതയിലും ഈ ഉൽപ്പന്നം നിർമ്മിച്ച പ്ലാറ്റ്‌ഫോമിന്റെ പക്വതയിലും അവർ ടീമുകളുടെ സന്നദ്ധതയെ ആശ്രയിക്കുന്നു. DevOps ആവശ്യമായിരിക്കുന്നത് എന്തുകൊണ്ടാണെന്ന് ഒരു ബിസിനസിനോട് എങ്ങനെ വിശദീകരിക്കാമെന്ന് മിഷ പറഞ്ഞു.

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

അടുത്ത പ്രധാന കുറിപ്പ്: DevOps എപ്പോഴും മാർക്കറ്റിലേക്കുള്ള സമയം കുറയ്ക്കില്ല. DevOps-ന് ഒറ്റയ്ക്ക് പ്രവർത്തിക്കാൻ കഴിയില്ല, ഇത് വികസനത്തിൽ നിന്ന് ഉൽപ്പാദനത്തിലേക്ക് (കോഡിൽ നിന്ന് ഉപഭോക്താവിലേക്ക്) ഒരു ഉൽപ്പന്നം സൃഷ്ടിക്കുന്നതിനും വിപണിയിലേക്ക് കൊണ്ടുവരുന്നതിനുമുള്ള പ്രക്രിയയുടെ ഒരു ഭാഗം മാത്രമാണ്. എന്നാൽ കോഡിന് മുമ്പുള്ള എല്ലാം DevOps-മായി നേരിട്ട് ബന്ധപ്പെട്ടതല്ല. അതായത്, വിപണനക്കാർക്ക് വർഷങ്ങളോളം വിപണി പഠിക്കാനും എതിരാളികളെ പിടിക്കാൻ അവരുടെ ജീവിതം മുഴുവൻ ചെലവഴിക്കാനും കഴിയും. ക്ലയന്റിന് എന്താണ് വേണ്ടതെന്ന് വേഗത്തിൽ മനസിലാക്കുകയും ഈ അല്ലെങ്കിൽ ആ സവിശേഷത നടപ്പിലാക്കാൻ ആസൂത്രണം ചെയ്യുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ് - പലപ്പോഴും ഇത് DevOps പ്രവർത്തിക്കാനും കമ്പനിക്ക് അതിന്റെ ലക്ഷ്യം നേടാനും പര്യാപ്തമല്ല. അതിനാൽ, ഒന്നാമതായി, DevOps എങ്ങനെ ഉപയോഗിക്കണമെന്ന് പഠിക്കേണ്ടത് അത്യാവശ്യമാണെന്ന് Raiffeisenbank ബിസിനസ്സിനോട് സമ്മതിച്ചു. ഓട്ടോമേഷനു വേണ്ടിയുള്ള ഓട്ടോമേഷൻ പുതിയ ഉപഭോക്താക്കൾക്കുള്ള പോരാട്ടത്തിൽ കാര്യമായി സഹായിക്കില്ല.

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

മാംഗോ ടെലികോമിലെ ടെസ്റ്റിംഗിന്റെ ഓട്ടോമേഷൻ

ഒരു ടെസ്റ്റർ എന്ന നിലയിൽ എനിക്ക് രസകരമായ മറ്റൊരു റിപ്പോർട്ട് മാംഗോ ടെലികോമിൽ നിന്നുള്ള എഗോർ മസ്ലോവ് നൽകി. "ഒരു SCRUM ടീമിലെ മുഴുവൻ ടെസ്റ്റിംഗ് സൈക്കിളിന്റെ ഓട്ടോമേഷൻ" എന്നാണ് അവതരണത്തിന്റെ പേര്. DevOps പ്രത്യേകമായി SCRUM-ന് വേണ്ടി സൃഷ്ടിച്ചതാണെന്ന് എഗോർ വിശ്വസിക്കുന്നു, എന്നാൽ അതേ സമയം, ഒരു SCRUM ടീമിലേക്ക് DevOps അവതരിപ്പിക്കുന്നത് തികച്ചും പ്രശ്‌നകരമാണ്. SCRUM ടീം എല്ലായ്‌പ്പോഴും എവിടെയെങ്കിലും പ്രവർത്തിക്കുന്നതിനാലാണ് ഇത് സംഭവിക്കുന്നത്, പുതുമകളിൽ നിന്ന് വ്യതിചലിക്കാനും പ്രക്രിയ പുനർനിർമ്മിക്കാനും സമയമില്ല. ടീമിലെ (ടെസ്റ്റിംഗ് ടീം, ഡെവലപ്‌മെന്റ് ടീം മുതലായവ) ഉപ-ടീമുകളുടെ വേർതിരിവ് SCRUM-ൽ ഉൾപ്പെടുന്നില്ല എന്ന വസ്തുതയിലും പ്രശ്‌നമുണ്ട്. ശരി, കൂടാതെ, നിലവിലുള്ള ഒരു പ്രോസസ്സ് ഓട്ടോമേറ്റ് ചെയ്യുന്നതിന്, ഡോക്യുമെന്റേഷൻ ആവശ്യമാണ്, കൂടാതെ SCRUM-ൽ, മിക്കപ്പോഴും ഡോക്യുമെന്റേഷൻ പൂർണ്ണമായും ഇല്ല - "ഏതെങ്കിലും തരത്തിലുള്ള എഴുത്തുകളേക്കാൾ ഉൽപ്പന്നം പ്രധാനമാണ്."

SCRUM-ലേക്ക് മാറിയതിനുശേഷം, ഫീച്ചറുകൾ എങ്ങനെ പരിശോധിക്കണം എന്നതിനെക്കുറിച്ച് ടെസ്റ്റർമാർ ഡവലപ്പർമാരുമായി കൂടിയാലോചിക്കാൻ തുടങ്ങി. ക്രമേണ, പ്രവർത്തനത്തിന്റെ അളവ് വർദ്ധിച്ചു, ഡോക്യുമെന്റേഷൻ ഇല്ലായിരുന്നു, കൂടാതെ ടെസ്റ്റുകളിൽ ഉൾപ്പെടാത്ത പ്രവർത്തനങ്ങളിൽ അവർ ധാരാളം ബഗുകൾ പിടിക്കാൻ തുടങ്ങി, ആരാണ് ഇത് പരീക്ഷിച്ചത്, എപ്പോൾ എന്ന് പൊതുവെ വ്യക്തമല്ല. ചുരുക്കത്തിൽ - ആശയക്കുഴപ്പവും ചാഞ്ചാട്ടവും. ടെസ്റ്റിംഗ് ഓട്ടോമേഷനിലേക്ക് മാറാൻ ഞങ്ങൾ തീരുമാനിച്ചു. എന്നാൽ അന്നും സമ്പൂർണ പരാജയം സംഭവിച്ചു. ഇൻ-ഹൗസ് ടെസ്റ്റർമാർക്ക് അജ്ഞാതമായ ഒരു സ്റ്റാക്കിൽ എഴുതിയ ഔട്ട്സോഴ്സ് ചെയ്ത ഓട്ടോമേഷൻ സ്പെഷ്യലിസ്റ്റുകളെ അവർ നിയമിച്ചു. ഓട്ടോടെസ്റ്റുകളുടെ ചട്ടക്കൂട് തീർച്ചയായും പ്രവർത്തിച്ചു, എന്നാൽ ഔട്ട്സോഴ്സർമാർ പോയതിനുശേഷം, അത് രണ്ടാഴ്ച നീണ്ടുനിന്നു. ഓട്ടോടെസ്റ്റിംഗ് നമ്പർ രണ്ട് അവതരിപ്പിക്കാനുള്ള ശ്രമമായിരുന്നു അടുത്തത്. SCRUM-ന്റെ ചട്ടക്കൂടിനുള്ളിൽ, കമ്പനിക്കുള്ളിൽ, നിങ്ങളുടേതായ (ശരിയായ വെക്റ്റർ: ആന്തരികമായി വൈദഗ്ദ്ധ്യം വളർത്തിയെടുക്കുക), പ്രക്രിയയിൽ ഡോക്യുമെന്റേഷൻ സൃഷ്ടിക്കേണ്ടതുണ്ട് എന്ന വസ്തുതയോടെയാണ് ഇത് ആരംഭിച്ചത്. ഓട്ടോമേഷനായുള്ള സ്റ്റാക്ക് ഉൽപ്പന്നത്തിന്റെ സ്റ്റാക്കിന് തുല്യമായിരിക്കണം (ഇവിടെ ഞാൻ അത് ചേർക്കുന്നു, നിങ്ങളുടെ JavaScript പ്രോജക്റ്റ് മറ്റെന്തെങ്കിലും ഉപയോഗിച്ച് പരീക്ഷിക്കരുത്). സ്പ്രിന്റിന്റെ അവസാനം, മുഴുവൻ ടീമുമായും ഓട്ടോടെസ്റ്റ് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിന്റെ ഒരു ഡെമോ അവർ നടത്തി (സഹായകരമാണ്). അങ്ങനെ, ഓട്ടോമേഷൻ പ്രക്രിയയിൽ എല്ലാ ടീം അംഗങ്ങളുടെയും പങ്കാളിത്തം വർദ്ധിച്ചു, കൂടാതെ ഓട്ടോടെസ്റ്റുകളിലെ വിശ്വാസവും ഈ ഓട്ടോടെസ്റ്റ് തീർച്ചയായും ഉപയോഗിക്കാനുള്ള സാധ്യതയും വർദ്ധിച്ചു (നിരന്തര പരാജയങ്ങൾ കാരണം ഒരു മാസത്തിനുള്ളിൽ അഭിപ്രായമിടില്ല).

വഴിയിൽ, DevOpsForum 2019-ൽ ഒരു തുറന്ന മൈക്രോഫോൺ ഉണ്ടായിരുന്നു - വളരെക്കാലമായി അറിയപ്പെടുന്നതും എന്റെ അഭിപ്രായത്തിൽ, പ്രസംഗങ്ങളുടെ ഉപയോഗപ്രദവുമായ ഫോർമാറ്റ്. നിങ്ങൾ ഇതുപോലെ ചുറ്റിനടക്കുക, റിപ്പോർട്ടുകൾ ശ്രദ്ധിക്കുക, തുടർന്ന് കോൺഫറൻസിൽ ഒരു പ്രത്യേക വിഷയമോ പ്രശ്നമോ ചർച്ചചെയ്യുന്നത് മൂല്യവത്താണെന്ന് തീരുമാനിക്കുക, പ്രശ്നം പരിഹരിക്കുന്നതിൽ പ്രസക്തമായ അനുഭവം പങ്കിടുക.

സംഘാടകർ ചെറിയ റിപ്പോർട്ടുകൾ ഉണ്ടാക്കിയതും ഞാൻ ശ്രദ്ധിച്ചു. ഓരോ റിപ്പോർട്ടും 10 മിനിറ്റിൽ കൂടുതൽ നീണ്ടുനിൽക്കില്ല, തുടർന്ന് ചോദ്യങ്ങൾ. ഇതുവഴി നിങ്ങൾക്ക് ഒരേസമയം നിരവധി വിഷയങ്ങൾ കവർ ചെയ്യാനും നിങ്ങൾക്ക് താൽപ്പര്യമുള്ള സ്പീക്കറുകളോട് ചോദ്യങ്ങൾ ചോദിക്കാനും കഴിയും.

അവതരണങ്ങൾക്കിടയിൽ, ഞാൻ കോൺഫറൻസ് പങ്കാളികളുടെ ബൂത്തുകളിൽ ചുറ്റിനടന്നു, ധാരാളം കാര്യങ്ങൾ മോഷ്ടിച്ചു/വിജയിച്ചു. ഓ, എനിക്ക് ഹാൻഡ്ഔട്ട് ഇഷ്ടമാണ്!

അൽഫാസ്ട്രഖോവാനിയിലെ ഡെവലപ്‌മെന്റ് ഡയറക്ടറുമായി വട്ടമേശയും DevOps പ്രശ്നങ്ങളും

DevOps വിദഗ്ധരുമായി ഒരു മണിക്കൂർ നീണ്ട പ്ലീനറി സെഷനാണ് എനിക്ക് DevOpsForum 2019 കേക്കിലെ ഐസിംഗ്. വിവിധ കോണുകളിൽ നിന്ന് DevOps നോക്കാൻ നാല് സെഷൻ പങ്കാളികളെ ക്ഷണിച്ചു: ആന്റൺ ഇസാനിൻ (അൽഫസ്ട്രഖോവാനി, ഡെവലപ്‌മെന്റ് ഡയറക്ടർ), നൈല്യ സമഷ്കിന (ഫിൻടെക് ലാബ്, ഓപ്പറേറ്റിംഗ് ഡയറക്ടർ), ഒലെഗ് എഗോർകിൻ (റോസ്‌റ്റെലെകോം, എജൈൽ കോച്ച്), ആന്റൺ മാർട്ടിയാനോവ് (സ്വതന്ത്ര വിദഗ്ധൻ, DevOps നോക്കി). ഒരു ബിസിനസ്സ് വീക്ഷണകോണിൽ നിന്ന്).

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

പിന്നെ, ഞാൻ ആന്റൺ ഇസാനിനുമായി വ്യക്തിപരമായി സംസാരിച്ചു. DevOps സംസ്കാരം എല്ലാ വീട്ടിലും എത്തിക്കേണ്ടതിന്റെ ആവശ്യകതയെക്കുറിച്ച് ഞങ്ങൾ ചർച്ച ചെയ്യുകയും DevOps പരിവർത്തനത്തിന്റെ ഇരുണ്ട വശം വെളിപ്പെടുത്തുകയും ചെയ്തു.

ഉൽപ്പന്നത്തിനും ബിസിനസ്സിനും ടീമിനും DevOps ആവശ്യമാണെന്ന് എല്ലാവരും ഒത്തുചേർന്ന് തീരുമാനിച്ചുവെന്ന് നമുക്ക് സങ്കൽപ്പിക്കുക. നമുക്ക് അത് നടപ്പിലാക്കാൻ പോകാം. എല്ലാം പ്രവർത്തിച്ചു. ഞങ്ങൾ ശ്വാസം വിട്ടു. DevOps ഞങ്ങളെ ക്ലയന്റിലേക്ക് അടുപ്പിച്ചു, ഇപ്പോൾ ഞങ്ങൾക്ക് അവന്റെ എല്ലാ ആഗ്രഹങ്ങളും വേഗത്തിൽ നിറവേറ്റാനാകും. തൽഫലമായി, ഞങ്ങൾക്ക് കർശനമായ നിയന്ത്രണങ്ങളും ആവശ്യകതകളും ഉള്ള ഒരു വലിയ Ops ഡിപ്പാർട്ട്‌മെന്റ് ഉണ്ട്, അത് ഉൽപ്പന്നത്തിൽ നിരന്തരം വൈകല്യങ്ങൾ കണ്ടെത്തുകയും ഒരു കൂട്ടം അഭ്യർത്ഥനകൾ സൃഷ്ടിക്കുകയും ചെയ്യുന്നു. മാത്രമല്ല, ക്ലയന്റ് അപ്രതീക്ഷിതമായി ബട്ടണിന് പച്ചയ്ക്ക് പകരം മഞ്ഞ നിറം നൽകണമെങ്കിൽ പോലും എല്ലാ വൈകല്യങ്ങൾക്കും "അടിയന്തിര" സ്റ്റാറ്റസ് നൽകിയിരിക്കുന്നു. പ്രോജക്റ്റ് വളരുകയാണ്, റിലീസുകളുടെ എണ്ണം വർദ്ധിച്ചുകൊണ്ടിരിക്കുകയാണ്, അതനുസരിച്ച്, ക്ലയന്റുകളുടെ പുതിയ പ്രവർത്തനത്തിന്റെ വൈകല്യങ്ങളുടെയും തെറ്റിദ്ധാരണകളുടെയും എണ്ണം. റിപ്പോർട്ടിംഗ് വൈകല്യങ്ങൾ നിലനിർത്താൻ Ops 10 പേരെ കൂടി നിയമിക്കുന്നു, അവ അടയ്ക്കുന്നത് തുടരാൻ വികസനം 15 പേരെ കൂടി നിയമിക്കുന്നു. പുതിയ ഫീച്ചറുകൾ അവതരിപ്പിക്കുന്നതിനുപകരം, ടീം അനന്തമായ SD-കൾക്കൊപ്പം പ്രവർത്തിക്കുന്നു, ഒരേ സമയം ഉപയോക്താവിന് പ്രവർത്തനക്ഷമതയും പിന്തുണയും വിശദീകരിക്കുന്നു. തൽഫലമായി, ഓപ്‌സും ഡെവലപ്‌മെന്റും ബിസിനസ്സിലാണ്, എന്നാൽ ക്ലയന്റും ബിസിനസും അസന്തുഷ്ടരാണ്: പുതിയ ഫീച്ചറുകൾ സ്തംഭിച്ചു. DevOps നിലവിലുണ്ടെന്ന് തോന്നുന്നു, പക്ഷേ അത് നിലവിലില്ലെന്ന് തോന്നുന്നു.

DevOps നടപ്പിലാക്കേണ്ടതിന്റെ ആവശ്യകതയെക്കുറിച്ച്, ഇത് ബിസിനസിന്റെ സ്കെയിലിനെ നേരിട്ട് ആശ്രയിച്ചിരിക്കുന്നുവെന്ന് ആന്റൺ വ്യക്തമായി പ്രസ്താവിച്ചു. പ്രതിവർഷം ഒരു ക്ലയന്റ് സേവനം കമ്പനിക്ക് ഒരു ബില്യൺ നൽകുന്നുവെങ്കിൽ, DevOps ആവശ്യമില്ല (നിങ്ങൾ ഈ ക്ലയന്റിലേക്ക് പതിവായി പുതിയ മാറ്റങ്ങൾ വരുത്തേണ്ടതില്ലെങ്കിൽ). എല്ലാം ചോക്കലേറ്റിൽ പൊതിഞ്ഞിരിക്കുന്നു. എന്നാൽ ബിസിനസ്സ് വളരുകയും കൂടുതൽ ക്ലയന്റുകൾ പ്രത്യക്ഷപ്പെടുകയും ചെയ്താൽ, നിങ്ങൾ അനുസരിക്കേണ്ടതുണ്ട്. ചട്ടം പോലെ, തുടക്കത്തിൽ കമ്പനിയിൽ രസകരമായ Ops ഇല്ല. ആദ്യം ഞങ്ങൾ ഉൽപ്പന്നം വെട്ടിക്കളഞ്ഞു, അതിനുശേഷം മാത്രമേ ഉൽപ്പന്നം പ്രവർത്തിക്കാൻ, സെർവറുകളിൽ ശ്രദ്ധ ചെലുത്തേണ്ടതും സപ്ലൈസ് നിരീക്ഷിക്കേണ്ടതും ഞങ്ങൾ മനസ്സിലാക്കുന്നു. അപ്പോഴാണ് Ops വരുന്നത്. Ops, ഒരു പ്രത്യേക ഡിവിഷൻ എന്ന നിലയിൽ, വികസനത്തിന് ഒരു കൂട്ടം തടസ്സങ്ങൾ സ്ഥാപിക്കാൻ തുടങ്ങുമെന്നും എല്ലാ ഡെലിവറികളും സ്തംഭിക്കാൻ തുടങ്ങുമെന്നും മനസ്സിലാക്കേണ്ടതുണ്ട്. അതായത്, ഈ സാഹചര്യത്തിൽ, DevOps സംസ്കാരം ഇതിനകം പ്രസക്തമാണ്, എന്നാൽ അതിന്റെ ഇരുണ്ട വശത്തെക്കുറിച്ച് നാം മറക്കരുത്.

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