എന്തിന് ഉപകരണങ്ങൾ മാത്രം DevOps ഉണ്ടാക്കുന്നില്ല

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

ഉപകരണങ്ങളല്ല പ്രശ്നം. അവയൊന്നും പ്രധാനമല്ല.

DevOps എന്തെല്ലാം പരിഹരിക്കണം

2009ൽ പാത്രിക് ഡെബോയിസ് ബെൽജിയത്തിൽ ആദ്യത്തെ ഡെവ് ഒപ്സ് ഡേ സംഘടിപ്പിച്ചപ്പോൾ "ഡെവ് ഒപ്പ്സ്" എന്ന വാക്ക് രൂപംകൊണ്ടു. അത് പരിഹരിച്ച പ്രശ്നം മനുഷ്യന്റെ പ്രശ്നമായിരുന്നു. ഡെവലപ്പർമാർക്ക് മാറ്റങ്ങൾ വേഗത്തിൽ എത്തിക്കണമെന്നും പ്രവർത്തനങ്ങൾ സ്ഥിരത ആവശ്യമാണെന്നും. അവര് ക്ക് വ്യത്യസ്ത ലക്ഷ്യങ്ങളുണ്ടായിരുന്നു, വ്യത്യസ്ത മാനേജര് മാരും വ്യത്യസ്ത പ്രോത്സാഹനങ്ങളും. അവര് യുദ്ധം ചെയ്തു, സോഫ്റ്റ്വെയര് വിതരണം വളരെ പതുക്കെയായിരുന്നു.

ഇവയെ ഒന്നിപ്പിക്കാന് DevOps നിർദ്ദേശിച്ചു: പങ്കിട്ട ലക്ഷ്യങ്ങള് , പങ്കിട്ട ഉത്തരവാദിത്തം , പങ്കിട്ട ഉപകരണങ്ങള് , ധാരാളം ഓട്ടോമേഷന് അങ്ങനെ വേഗതയും സ്ഥിരതയും എതിര് ക്കല് അവസാനിപ്പിക്കും.

ഓർഡര് ശ്രദ്ധിക്കുക. ആളുകളും ലക്ഷ്യങ്ങളും ആദ്യം, അവയെ പിന്തുണയ്ക്കുന്നതിനുള്ള ഉപകരണങ്ങളും.

CALMS ചട്ടക്കൂട്

DevOps നെക്കുറിച്ച് ചിന്തിക്കാന് ഒരു ഉപകാരപ്രദമായ മാർഗ്ഗം ഇതാണ് ശാന്തമായി, ജെസ് ഹംബിളും മറ്റുള്ളവരും പ്രചരിപ്പിച്ച ഒരു ചട്ടക്കൂട്:

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

ഉപകരണങ്ങള് കൂടുതലും A യും M ന്റെ ഒരു ഭാഗവും മൂടുന്നു. സി, എൽ, എസ് എന്നിവയെല്ലാം ആളുകൾ എങ്ങനെ ഒരുമിച്ചു പ്രവർത്തിക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

ഉപകരണങ്ങൾ നല്ല സഹകരണം വേഗത്തിലാക്കുന്നു. അവ മോശം സഹകരണം വേഗത്തിലാക്കുന്നു.

"പേരിന് മാത്രം ഡെവൊപ്സ്" എന്നതിന്റെ അടയാളങ്ങൾ

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

സിലോസ് തകര് ക്കല്

ശരിക്കും സഹായിക്കുന്നതെന്താണ്:

• പൊതു ലക്ഷ്യങ്ങള് . ഒരേ ഫലങ്ങളില് അളക്കുന്ന ഡെവലപ്പര് മാരും പ്രവർത്തനങ്ങളും: നടപ്പാക്കല് വേഗത ഒപ്പം ഓരോരുത്തര് ക്കും ഓരോരുത്തര് ക്ക് ഓരോരുത്തര് ക്കുമില്ല.
• "നിങ്ങൾ അത് നിർമ്മിക്കുകയും പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുന്നു", പിന്തുണയോടെ. ടീമുകൾക്ക് അവരുടെ സേവനങ്ങൾ സ്വന്തമാണ്, ഡിമാൻഡ് ഉൾപ്പെടെ, പ്ലാറ്റ്ഫോം ടീമുകൾ അത് കൈകാര്യം ചെയ്യാൻ കഴിയും.
• സേവനം നൽകുന്ന പ്ലാറ്റ്ഫോം ടീമുകൾ, സ്വയം സേവന ഉപകരണങ്ങൾ നിർമ്മിക്കുന്നു, അത് ഡെവലപ്പർമാർക്ക് സ്വതന്ത്രമായി പ്രവർത്തിക്കാൻ അനുവദിക്കുന്നു, അവർക്ക് വേണ്ടി ജോലി ചെയ്യുന്നതിനുപകരം.
• ഉൾപ്പെടുത്തൽ: ഒരു പ്രൊഡക്ട് ടീമിനുള്ളിൽ കുറച്ചു കാലം ജോലി ചെയ്യുന്ന ഒരു SRE അല്ലെങ്കിൽ പ്ലാറ്റ്ഫോം എഞ്ചിനീയർ, ഇരുവശത്തും അറിവ് പങ്കിടുന്നു.
• പങ്കുവെച്ച ആചാരങ്ങൾസംയുക്തമായ പോസ്റ്റ്മോർട്ടം, പങ്കിട്ട ഡാഷ്ബോർഡുകൾ, ടീമുകളിലെ പ്രദർശനങ്ങൾ.

സംസാരിക്കാന് സുരക്ഷിതത്വം തോന്നുന്നു

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

ഡൊറയുടെ പഠനം സമാനമായ ഒരു കാര്യം പറയുന്നു. ജനറേറ്റീവ് സംസ്കാരം, വിവരങ്ങള് സ്വതന്ത്രമായി ഒഴുകുന്നു, പരാജയം കുറ്റപ്പെടുത്തുന്നതിനു പകരം അന്വേഷണത്തിലേക്ക് നയിക്കുന്നു, മെച്ചപ്പെട്ട സോഫ്റ്റ്വെയര് വിതരണവും മെച്ചപ്പെട്ട ക്ഷേമവും പ്രവചിക്കുന്നു.

പ്രായോഗികമായി, DevOps ലെ മനഃശാസ്ത്രപരമായ സുരക്ഷ ഇങ്ങനെ കാണപ്പെടുന്നുഃ

• കുറ്റമറ്റ പോസ്റ്റ്മോർട്ടങ്ങൾ ചോദ്യം "എങ്ങനെ സിസ്റ്റം ഇത് അനുവദിച്ചു" എന്നതല്ല "ആരാണ് ഇത് ചെയ്തത്" എന്നതല്ല.
• പേടിയില്ലാതെ "എനിക്കറിയില്ല" അല്ലെങ്കിൽ "ഞാൻ അത് തകർത്തു" എന്ന് പറയുന്ന ആളുകൾ.
• ജൂനിയർമാർ പൊതു ചാനലുകളിൽ ചോദ്യങ്ങൾ ചോദിക്കുന്നതിൽ സുഖമാണ്.
• തങ്ങളുടെ തെറ്റുകൾ ആദ്യം സമ്മതിക്കുന്ന നേതാക്കൾ.

അത് ഇല്ലാതെ, പ്രശ്നങ്ങൾ മറഞ്ഞിരിക്കും, മറഞ്ഞിരിക്കുന്ന പ്രശ്നങ്ങൾ വൈദ്യുതി മുടക്കുകളായി മാറും.

മാറ്റത്തിന് നേതൃത്വം നല് കുക

നിങ്ങളുടെ സംഘടനയെ യഥാർഥ DevOps-ലേക്ക് നീക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കില്:

1. എല്ലാവരും അനുഭവിക്കുന്ന വേദനയുള്ള ഒരു പോയിന്റ് ഉപയോഗിച്ച് തുടങ്ങുക.: വേഗത കുറഞ്ഞ റിലീസുകൾ, വേദനയേറിയ വിന്യാസങ്ങൾ, പതിവ് സംഭവങ്ങൾ.
2. ഒരു ടീം തിരഞ്ഞെടുക്കുക. വ്യത്യസ്തമായ രീതിയില് ശ്രമിക്കാന് തയ്യാറായി. ഫലങ്ങള് കാണിക്കൂ.
3. അളവ് മുമ്പും ശേഷവും (ഡോറ അളവുകൾ ഇതിനു നല്ലതാണ്).
4. ഓട്ടോമേഷന് നിക്ഷേപം അത് ഏറ്റവും വേദനയേറിയ കരകൌശല ജോലിയെ ഇല്ലാതാക്കുന്നു.
5. മാറ്റം വരുത്താനുള്ള പ്രോത്സാഹനം: പ്രതിഫലം ലഭിക്കുകയും അളക്കുകയും ചെയ്യുന്നവയാണ് ഏതെങ്കിലും ഉപകരണത്തേക്കാൾ പെരുമാറ്റത്തെ രൂപപ്പെടുത്തുന്നത്.
6. നേതൃത്വത്തിന്റെ പിന്തുണ നേടുക. സംസ്കാരം താഴേത്തട്ടിൽ നിന്നും മുകളിലേക്കും മാറുന്നു.
7. ക്ഷമയോടെയിരിക്കൂ. സംസ്കാര മാറ്റത്തിന് വർഷങ്ങളേ എടുക്കൂ, സ്പ്രിന്റുകളല്ല.

അതായത്, ഉപകരണങ്ങള് പ്രയോജനമില്ലാത്തതാണോ?

ഒരു കാര്യവുമില്ല. നല്ല ഉപകരണങ്ങള് നല്ല രീതികള് സാധ്യമാക്കുകയും സ്കേലബിളാക്കുകയും ചെയ്യുന്നു. പക്ഷെ വ്യത്യസ്തമായി ഒരുമിച്ച് പ്രവർത്തിക്കാനുള്ള തീരുമാനത്തിനു ശേഷമാണ് അവ വരുന്നത്, പകരം അല്ല.

എന്റെ അഭിപ്രായം: DevOps എന്നത് നിങ്ങൾ പരിശീലിക്കുന്ന ഒന്നാണ്, നിങ്ങൾ വാങ്ങുന്ന ഒന്നല്ല. ഉപകരണങ്ങള് എളുപ്പമുള്ള ഭാഗമാണ്. ജനങ്ങളാണ് പ്രധാനം.

ഡെസ്ലി