ഞങ്ങൾ DevOps-നെ കുറിച്ച് മനസ്സിലാക്കാവുന്ന ഭാഷയിൽ സംസാരിക്കുന്നു

DevOps-നെക്കുറിച്ച് പറയുമ്പോൾ പ്രധാന കാര്യം മനസ്സിലാക്കാൻ പ്രയാസമാണോ? സ്പെഷ്യലിസ്റ്റുകൾ അല്ലാത്തവരെപ്പോലും വിഷയത്തിലേക്ക് കൊണ്ടുവരാൻ സഹായിക്കുന്ന ഉജ്ജ്വലമായ സാമ്യങ്ങളും ശ്രദ്ധേയമായ ഫോർമുലേഷനുകളും വിദഗ്ധരിൽ നിന്നുള്ള ഉപദേശങ്ങളും ഞങ്ങൾ നിങ്ങൾക്കായി ശേഖരിച്ചിട്ടുണ്ട്. അവസാനം, ബോണസ് Red Hat ജീവനക്കാരുടെ സ്വന്തം DevOps ആണ്.

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

അതിനാൽ, DevOps-നെ കുറിച്ചുള്ള ചോദ്യങ്ങൾ നിങ്ങൾക്ക് പലപ്പോഴും കേൾക്കാം, ഇത് ചടുലതയ്ക്ക് തുല്യമാണോ? അതോ ഇത് എന്തെങ്കിലും പ്രത്യേക രീതിശാസ്ത്രമാണോ? അതോ "സഹകരണം" എന്ന വാക്കിൻ്റെ മറ്റൊരു പര്യായമാണോ?

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

എന്താണ് DevOps: 6 നിർവചനങ്ങളും സമാനതകളും

DevOps-ൻ്റെ സാരാംശം കഴിയുന്നത്ര ലളിതമായും ഹ്രസ്വമായും വിശദീകരിക്കാൻ ഞങ്ങൾ വിദഗ്ധരോട് ആവശ്യപ്പെട്ടു, അതുവഴി ഏത് തലത്തിലുള്ള സാങ്കേതിക പരിജ്ഞാനമുള്ള വായനക്കാർക്ക് അതിൻ്റെ മൂല്യം വ്യക്തമാകും. ഈ സംഭാഷണങ്ങളുടെ ഫലങ്ങളെ അടിസ്ഥാനമാക്കി, DevOps-നെക്കുറിച്ചുള്ള നിങ്ങളുടെ സ്റ്റോറി നിർമ്മിക്കാൻ നിങ്ങളെ സഹായിക്കുന്ന ഏറ്റവും ശ്രദ്ധേയമായ സാമ്യങ്ങളും ശ്രദ്ധേയമായ ഫോർമുലേഷനുകളും ഞങ്ങൾ തിരഞ്ഞെടുത്തു.

1. DevOps ഒരു സാംസ്കാരിക പ്രസ്ഥാനമാണ്

"DevOps എന്നത് ഒരു സാംസ്കാരിക പ്രസ്ഥാനമാണ്, അതിൽ രണ്ട് കക്ഷികളും (സോഫ്‌റ്റ്‌വെയർ ഡെവലപ്പർമാരും ഐടി സിസ്റ്റം ഓപ്പറേഷൻ സ്പെഷ്യലിസ്റ്റുകളും) സോഫ്റ്റ്‌വെയർ ഉപയോഗിക്കാൻ തുടങ്ങുന്നത് വരെ യഥാർത്ഥ നേട്ടങ്ങൾ നൽകുന്നില്ലെന്ന് തിരിച്ചറിയുന്നു: ഉപഭോക്താക്കൾ, ക്ലയൻ്റുകൾ, ജീവനക്കാർ, പ്രധാനം അല്ല," സീനിയർ റിസർച്ച് എവ്‌ലൈൻ ഒഹ്‌ലിച് പറയുന്നു. DevOps ഇൻസ്റ്റിറ്റ്യൂട്ടിലെ അനലിസ്റ്റ്. "അതിനാൽ, ഈ രണ്ട് കക്ഷികളും സംയുക്തമായി സോഫ്റ്റ്‌വെയറിൻ്റെ വേഗത്തിലുള്ളതും ഉയർന്ന നിലവാരമുള്ളതുമായ ഡെലിവറി ഉറപ്പാക്കുന്നു."

2. ഡെവലപ്പർമാരെ ശാക്തീകരിക്കുന്നതാണ് DevOps.

"DevOps ഡെവലപ്പർമാരെ ആപ്ലിക്കേഷനുകൾ സ്വന്തമാക്കാനും അവ പ്രവർത്തിപ്പിക്കാനും തുടക്കം മുതൽ അവസാനം വരെ ഡെലിവറി നിയന്ത്രിക്കാനും പ്രാപ്തരാക്കുന്നു."

"സാധാരണഗതിയിൽ, ഓട്ടോമേറ്റഡ് പ്രോസസുകൾ നിർമ്മിക്കുകയും നടപ്പിലാക്കുകയും ചെയ്തുകൊണ്ട് പ്രൊഡക്ഷനിലേക്ക് ആപ്ലിക്കേഷനുകളുടെ ഡെലിവറി വേഗത്തിലാക്കാനുള്ള ഒരു മാർഗമായാണ് DevOps സംസാരിക്കപ്പെടുന്നത്," ഇൻഷുറൻസ് കമ്പനിയായ ലിബർട്ടി മ്യൂച്വലിലെ DevOps പ്ലാറ്റ്‌ഫോമുകളുടെ ഡയറക്ടർ ജയ് ഷ്‌നിപ്പ് പറയുന്നു. "എന്നാൽ എന്നെ സംബന്ധിച്ചിടത്തോളം ഇത് കൂടുതൽ അടിസ്ഥാനപരമായ കാര്യമാണ്." DevOps ഡെവലപ്പർമാരെ ആപ്ലിക്കേഷനുകളോ നിർദ്ദിഷ്ട സോഫ്‌റ്റ്‌വെയറുകളോ സ്വന്തമാക്കാനും അവ പ്രവർത്തിപ്പിക്കാനും അവരുടെ ഡെലിവറി തുടക്കം മുതൽ അവസാനം വരെ നിയന്ത്രിക്കാനും പ്രാപ്‌തമാക്കുന്നു. DevOps ഉത്തരവാദിത്ത ആശയക്കുഴപ്പം ഇല്ലാതാക്കുകയും ഒരു ഓട്ടോമേറ്റഡ്, ഡെവലപ്പർ നയിക്കുന്ന ഇൻഫ്രാസ്ട്രക്ചർ സൃഷ്ടിക്കുന്നതിൽ ഏർപ്പെട്ടിരിക്കുന്ന എല്ലാവരെയും നയിക്കുകയും ചെയ്യുന്നു.

3. DevOps എന്നത് ആപ്ലിക്കേഷനുകൾ സൃഷ്ടിക്കുന്നതിലും ഡെലിവറി ചെയ്യുന്നതിലുമുള്ള സഹകരണത്തെക്കുറിച്ചാണ്.

"ലളിതമായി പറഞ്ഞാൽ, എല്ലാവരും ഒരുമിച്ച് പ്രവർത്തിക്കുന്ന സോഫ്റ്റ്‌വെയർ നിർമ്മാണത്തിനും വിതരണത്തിനുമുള്ള ഒരു സമീപനമാണ് DevOps," ബിഎംസിയിലെ ഡിജിറ്റൽ ബിസിനസ് ഓട്ടോമേഷൻ പ്രസിഡൻ്റും മേധാവിയുമായ ഗുർ സ്റ്റാഫ് പറയുന്നു.

4. DevOps ഒരു പൈപ്പ് ലൈൻ ആണ്

"എല്ലാ ഭാഗങ്ങളും ഒരുമിച്ച് യോജിപ്പിച്ചാൽ മാത്രമേ കൺവെയർ അസംബ്ലി സാധ്യമാകൂ."

“ഞാൻ DevOps ഒരു കാർ അസംബ്ലി ലൈനുമായി താരതമ്യം ചെയ്യും,” ഗുർ സ്റ്റാഫ് തുടരുന്നു. - എല്ലാ ഭാഗങ്ങളും മുൻകൂട്ടി രൂപകൽപ്പന ചെയ്‌ത് നിർമ്മിക്കുക എന്നതാണ് ആശയം, അതുവഴി വ്യക്തിഗത ക്രമീകരണം കൂടാതെ അവ കൂട്ടിച്ചേർക്കാനാകും. എല്ലാ ഭാഗങ്ങളും ഒരുമിച്ച് യോജിപ്പിച്ചാൽ മാത്രമേ കൺവെയർ അസംബ്ലി സാധ്യമാകൂ. ഒരു എഞ്ചിൻ രൂപകൽപ്പന ചെയ്യുകയും നിർമ്മിക്കുകയും ചെയ്യുന്നവർ അത് ബോഡിയിലോ ഫ്രെയിമിലോ എങ്ങനെ ഘടിപ്പിക്കണമെന്ന് പരിഗണിക്കണം. ബ്രേക്ക് ഇടുന്നവർ ചക്രങ്ങളെക്കുറിച്ചും മറ്റും ചിന്തിക്കണം. സോഫ്റ്റ്‌വെയറിൻ്റെ കാര്യത്തിലും ഇതുതന്നെയായിരിക്കണം.

ബിസിനസ്സ് ലോജിക് അല്ലെങ്കിൽ ഒരു ഉപയോക്തൃ ഇൻ്റർഫേസ് സൃഷ്ടിക്കുന്ന ഒരു ഡെവലപ്പർ, ഉപഭോക്തൃ വിവരങ്ങൾ സംഭരിക്കുന്ന ഡാറ്റാബേസ്, ഉപയോക്തൃ ഡാറ്റ പരിരക്ഷിക്കുന്നതിനുള്ള സുരക്ഷാ നടപടികൾ, ഒരു വലിയ, ഒരുപക്ഷേ കോടിക്കണക്കിന് ഡോളർ ഉപയോക്തൃ പ്രേക്ഷകർക്ക് സേവനം നൽകാൻ തുടങ്ങുമ്പോൾ ഇതെല്ലാം എങ്ങനെ പ്രവർത്തിക്കും എന്നിവയെക്കുറിച്ച് ചിന്തിക്കണം. ."

“സ്വന്തം ജോലികളിൽ മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നതിനുപകരം മറ്റുള്ളവർ ചെയ്യുന്ന ജോലിയുടെ ഭാഗങ്ങളെക്കുറിച്ച് സഹകരിക്കാനും ചിന്തിക്കാനും ആളുകളെ പ്രേരിപ്പിക്കുന്നത് മറികടക്കാനുള്ള ഏറ്റവും വലിയ തടസ്സമാണ്. നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയുമെങ്കിൽ, നിങ്ങൾക്ക് ഡിജിറ്റൽ പരിവർത്തനത്തിനുള്ള മികച്ച അവസരമുണ്ട്, ”ഗുർ സ്റ്റാഫ് കൂട്ടിച്ചേർക്കുന്നു.

5. ആളുകൾ, പ്രക്രിയകൾ, ഓട്ടോമേഷൻ എന്നിവയുടെ ശരിയായ സംയോജനമാണ് DevOps

DevOps ഇൻസ്റ്റിറ്റ്യൂട്ടിൻ്റെ എക്സിക്യൂട്ടീവ് ഡയറക്ടർ ജെയ്ൻ ഗ്രോൾ, DevOps വിശദീകരിക്കാൻ ഒരു വലിയ സാമ്യം വാഗ്ദാനം ചെയ്തു. അവളുടെ വാക്കുകളിൽ, “DevOps എന്നത് മൂന്ന് പ്രധാന ചേരുവകളുള്ള ഒരു പാചകക്കുറിപ്പ് പോലെയാണ്: ആളുകൾ, പ്രോസസ്സ്, ഓട്ടോമേഷൻ. ഈ ചേരുവകളിൽ ഭൂരിഭാഗവും മറ്റ് മേഖലകളിൽ നിന്നും ഉറവിടങ്ങളിൽ നിന്നും എടുക്കാം: ലീൻ, എജൈൽ, SRE, CI/CD, ITIL, നേതൃത്വം, സംസ്കാരം, ഉപകരണങ്ങൾ. DevOps-ൻ്റെ രഹസ്യം, ഏതൊരു നല്ല പാചകക്കുറിപ്പും പോലെ, ആപ്ലിക്കേഷനുകൾ സൃഷ്ടിക്കുന്നതിനും റിലീസ് ചെയ്യുന്നതിനുമുള്ള വേഗതയും കാര്യക്ഷമതയും വർദ്ധിപ്പിക്കുന്നതിന് ഈ ചേരുവകളുടെ ശരിയായ അനുപാതങ്ങളും മിശ്രിതവും എങ്ങനെ നേടാം എന്നതാണ്.

6. ഒരു ഫോർമുല 1 ടീമിനെപ്പോലെ പ്രോഗ്രാമർമാർ പ്രവർത്തിക്കുന്നതാണ് DevOps

"ഓട്ടം തുടക്കം മുതൽ അവസാനം വരെ ആസൂത്രണം ചെയ്തിട്ടില്ല, മറിച്ച്, അവസാനം മുതൽ തുടക്കം വരെ."

“DevOps സംരംഭത്തിൽ നിന്ന് എന്താണ് പ്രതീക്ഷിക്കേണ്ടതെന്ന് ഞാൻ പറയുമ്പോൾ, ഒരു NASCAR അല്ലെങ്കിൽ ഫോർമുല 1 റേസിംഗ് ടീമിനെയാണ് ഞാൻ ഒരു ഉദാഹരണമായി കരുതുന്നത്,” Red Hat-ലെ ക്ലൗഡ് പ്ലാറ്റ്‌ഫോം മാർക്കറ്റിംഗിൻ്റെ സീനിയർ മാനേജരും DevOps'ish വാർത്താക്കുറിപ്പിൻ്റെ പ്രസാധകനുമായ ക്രിസ് ഷോർട്ട് പറയുന്നു. - അത്തരമൊരു ടീമിൻ്റെ നേതാവിന് ഒരു ലക്ഷ്യമുണ്ട്: ടീമിന് ലഭ്യമായ വിഭവങ്ങളും അതിന് നേരിട്ട വെല്ലുവിളികളും കണക്കിലെടുത്ത് ഓട്ടത്തിൻ്റെ അവസാനത്തിൽ സാധ്യമായ ഏറ്റവും ഉയർന്ന സ്ഥാനം നേടുക. ഈ സാഹചര്യത്തിൽ, ഓട്ടം ആസൂത്രണം ചെയ്തിരിക്കുന്നത് തുടക്കം മുതൽ അവസാനം വരെയല്ല, മറിച്ച്, അവസാനം മുതൽ ആരംഭം വരെയാണ്. ആദ്യം, ഒരു അഭിലാഷ ലക്ഷ്യം സജ്ജീകരിച്ചിരിക്കുന്നു, തുടർന്ന് അത് നേടാനുള്ള വഴികൾ നിർണ്ണയിക്കപ്പെടുന്നു. തുടർന്ന് അവ ഉപ ടാസ്‌ക്കുകളായി വിഭജിക്കുകയും ടീം അംഗങ്ങൾക്ക് നിയുക്തമാക്കുകയും ചെയ്യുന്നു.

“ഓട്ടത്തിന് മുമ്പുള്ള ആഴ്ച മുഴുവൻ ടീം പിറ്റ് സ്റ്റോപ്പ് മികച്ചതാക്കുന്നു. കഠിനമായ റേസ് ദിനത്തിൽ ആകാരത്തിൽ തുടരാൻ അവൻ ശക്തി പരിശീലനവും കാർഡിയോയും ചെയ്യുന്നു. ഓട്ടത്തിനിടയിൽ ഉണ്ടായേക്കാവുന്ന ഏത് പ്രശ്‌നങ്ങളും പരിഹരിക്കാൻ ഒരുമിച്ച് പ്രവർത്തിക്കുന്ന രീതികൾ. അതുപോലെ, പുതിയ പതിപ്പുകൾ ഇടയ്ക്കിടെ പുറത്തിറക്കാനുള്ള കഴിവ് ഡെവലപ്‌മെൻ്റ് ടീം പരിശീലിപ്പിക്കണം. നിങ്ങൾക്ക് അത്തരം കഴിവുകളും നന്നായി പ്രവർത്തിക്കുന്ന സുരക്ഷാ സംവിധാനവും ഉണ്ടെങ്കിൽ, ഉൽപ്പാദനത്തിലേക്ക് പുതിയ പതിപ്പുകളുടെ സമാരംഭവും പലപ്പോഴും സംഭവിക്കുന്നു. ഈ ലോകവീക്ഷണത്തിൽ, വേഗത വർധിച്ചാൽ, സുരക്ഷ വർധിപ്പിക്കുന്നു," ഷോർട്ട് പറയുന്നു.

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

DevOps എങ്ങനെ സ്കെയിൽ ചെയ്യാം: വിദഗ്ധരിൽ നിന്നുള്ള 10 നുറുങ്ങുകൾ

DevOps ഉം മാസ് DevOps ഉം തികച്ചും വ്യത്യസ്തമായ കാര്യങ്ങളാണെന്ന് മാത്രം. ആദ്യത്തേതിൽ നിന്ന് രണ്ടാമത്തേതിലേക്കുള്ള വഴിയിലെ തടസ്സങ്ങൾ എങ്ങനെ മറികടക്കാമെന്ന് ഞങ്ങൾ നിങ്ങളോട് പറയും.

പല സ്ഥാപനങ്ങൾക്കും, DevOps-ലേക്കുള്ള യാത്ര എളുപ്പത്തിലും സന്തോഷകരമായും ആരംഭിക്കുന്നു. ചെറിയ ആവേശകരമായ ടീമുകൾ സൃഷ്ടിക്കപ്പെടുന്നു, പഴയ പ്രക്രിയകൾ പുതിയവ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നു, ആദ്യ വിജയങ്ങൾ വരാൻ അധികനാളില്ല.

അയ്യോ, ഇതൊരു തെറ്റായ മിഥ്യാധാരണയാണ്, പുരോഗതിയുടെ മിഥ്യയാണ്, നോർത്ത് ഹൈലാൻഡിലെ കൺസൾട്ടൻസി മാനേജിംഗ് ഡയറക്ടറും ഡിജിറ്റൽ മേധാവിയുമായ ബെൻ ഗ്രിനെൽ പറയുന്നു. നേരത്തെയുള്ള വിജയങ്ങൾ തീർച്ചയായും പ്രോത്സാഹജനകമാണ്, എന്നാൽ സ്ഥാപനത്തിലുടനീളം DevOps വ്യാപകമായി സ്വീകരിക്കുക എന്ന ആത്യന്തിക ലക്ഷ്യം കൈവരിക്കാൻ അവ സഹായിക്കുന്നില്ല.

"നമ്മളും" "അവരും" തമ്മിലുള്ള വിഭജന സംസ്കാരമാണ് ഫലം എന്ന് കാണാൻ എളുപ്പമാണ്.

"പലപ്പോഴും, ഓർഗനൈസേഷനുകൾ ഈ പയനിയറിംഗ് പ്രോജക്റ്റുകൾ സമാരംഭിക്കുന്നത്, അവർ മുഖ്യധാരാ DevOps-ന് വഴിയൊരുക്കുമെന്ന് കരുതി, മറ്റുള്ളവർക്ക് ആ പാത പിന്തുടരാൻ കഴിയുമോ അതോ തയ്യാറാണോ എന്ന് പരിഗണിക്കാതെ," ബെൻ ഗ്രിനെൽ വിശദീകരിക്കുന്നു. - അത്തരം പ്രോജക്റ്റുകൾ നടപ്പിലാക്കുന്നതിനുള്ള ടീമുകൾ സാധാരണയായി മറ്റ് സ്ഥലങ്ങളിൽ സമാനമായ എന്തെങ്കിലും ചെയ്തിട്ടുള്ള, എന്നാൽ നിങ്ങളുടെ ഓർഗനൈസേഷനിൽ പുതിയവരായ ആത്മവിശ്വാസമുള്ള "വരംഗിയൻസിൽ" നിന്നാണ് സാധാരണയായി റിക്രൂട്ട് ചെയ്യുന്നത്. അതേസമയം, മറ്റെല്ലാവർക്കും ബാധകമായ നിയമങ്ങൾ ലംഘിക്കാനും നശിപ്പിക്കാനും അവരെ പ്രോത്സാഹിപ്പിക്കുന്നു. അറിവും നൈപുണ്യവും കൈമാറ്റം ചെയ്യുന്നതിനെ തടയുന്ന "ഞങ്ങൾ", "അവർ" എന്നിവയുടെ ഒരു സംസ്കാരമാണ് ഫലം എന്ന് കാണാൻ എളുപ്പമാണ്.

“ഈ സാംസ്കാരിക പ്രശ്നം DevOps സ്കെയിൽ ചെയ്യാൻ പ്രയാസമുള്ളതിൻ്റെ ഒരു കാരണം മാത്രമാണ്. അതിവേഗം വളരുന്ന ഐടി-ആദ്യ കമ്പനികളുടെ സാധാരണമായ സാങ്കേതിക വെല്ലുവിളികൾ DevOps ടീമുകൾ അഭിമുഖീകരിക്കുന്നു," സ്‌കലിറിൻ്റെ സ്ഥാപകനും ചെയർമാനുമായ സ്റ്റീവ് ന്യൂമാൻ പറഞ്ഞു.

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

മുകളിൽ വിവരിച്ച ഈ വെല്ലുവിളികളെ അതിജീവിച്ച് ഒരു വലിയ സ്ഥാപനത്തിൽ DevOps വൻതോതിൽ സ്വീകരിക്കുന്നതിലേക്ക് എങ്ങനെ നീങ്ങാം? നിങ്ങളുടെ സോഫ്റ്റ്‌വെയർ ഡെവലപ്‌മെൻ്റ് സൈക്കിളും ബിസിനസ്സ് പ്രക്രിയകളും വേഗത്തിലാക്കുക എന്നതാണ് നിങ്ങളുടെ ആത്യന്തിക ലക്ഷ്യം എങ്കിൽപ്പോലും, വിദഗ്ദ്ധർ ക്ഷമയോടെ അഭ്യർത്ഥിക്കുന്നു.

1. സംസ്കാരം മാറ്റാൻ സമയമെടുക്കുമെന്ന് ഓർക്കുക.

DevOps ഇൻസ്റ്റിറ്റ്യൂട്ട് എക്സിക്യൂട്ടീവ് ഡയറക്ടർ ജെയ്ൻ ഗ്രോൾ: “എൻ്റെ അഭിപ്രായത്തിൽ, DevOps-ൻ്റെ വിപുലീകരണം ചടുലമായ വികസനം പോലെ (സംസ്കാരത്തെ തുല്യമായി സ്പർശിക്കുന്നതും) വർദ്ധനയുള്ളതും ആവർത്തിച്ചുള്ളതുമായിരിക്കണം. Agile, DevOps എന്നിവ ചെറിയ ടീമുകൾക്ക് പ്രാധാന്യം നൽകുന്നു. എന്നാൽ ഈ ടീമുകൾ എണ്ണത്തിലും സംയോജനത്തിലും വളരുമ്പോൾ, കൂടുതൽ ആളുകൾ പുതിയ പ്രവർത്തന രീതികൾ സ്വീകരിക്കുന്നതിലേക്ക് ഞങ്ങൾ എത്തിച്ചേരുന്നു, അതിൻ്റെ ഫലമായി ഒരു വലിയ സാംസ്കാരിക പരിവർത്തനമുണ്ട്.

2. പ്ലാൻ ചെയ്യാനും പ്ലാറ്റ്ഫോം തിരഞ്ഞെടുക്കാനും മതിയായ സമയം ചെലവഴിക്കുക

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

“പിന്നെ ഇൻ്റഗ്രേഷൻ ആൻഡ് ടെസ്റ്റിംഗ് ഘട്ടം വരുന്നു, അവിടെ ഓട്ടോമേഷനായി സ്കെയിലബിൾ പ്ലാറ്റ്ഫോം ഇതിനകം ആവശ്യമാണ്. ഇവിടെയാണ് DevOps ടീമുകൾക്ക് അവരുടെ നൈപുണ്യ നിലയ്ക്കും പ്രോജക്റ്റിൻ്റെ അന്തിമ ലക്ഷ്യങ്ങൾക്കും അനുയോജ്യമായ ശരിയായ പ്ലാറ്റ്ഫോം തിരഞ്ഞെടുക്കേണ്ടത്.

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

3. കുറ്റബോധം ഉത്തരവാദിത്തത്തിൽ നിന്ന് എടുക്കുക.

ഗോർഡൻ ഹാഫ്, റെഡ്ഹാറ്റ് സുവിശേഷകൻ: “പരീക്ഷണങ്ങൾ അനുവദിക്കുകയും പ്രോത്സാഹിപ്പിക്കുകയും ചെയ്യുന്ന ഒരു സിസ്റ്റവും അന്തരീക്ഷവും സൃഷ്ടിക്കുന്നത്, ചടുലമായ സോഫ്റ്റ്‌വെയർ വികസനത്തിലെ വിജയകരമായ പരാജയങ്ങൾ എന്നറിയപ്പെടുന്നവയെ അനുവദിക്കുന്നു. പരാജയങ്ങൾക്ക് മറ്റാരും ഉത്തരവാദികളല്ല എന്നല്ല ഇതിനർത്ഥം. വാസ്തവത്തിൽ, ആരാണ് ഉത്തരവാദിയെന്ന് തിരിച്ചറിയുന്നത് കൂടുതൽ എളുപ്പമായിത്തീരുന്നു, കാരണം “ഉത്തരവാദിത്തം” എന്നാൽ “അപകടം ഉണ്ടാക്കുക” എന്നല്ല അർത്ഥമാക്കുന്നത്. അതായത്, ഉത്തരവാദിത്തത്തിൻ്റെ സാരാംശം ഗുണപരമായി മാറുന്നു. നാല് ഘടകങ്ങൾ നിർണായകമാണ്: തടസ്സത്തിൻ്റെ വ്യാപ്തി, സമീപനങ്ങൾ, ഉൽപ്പാദന പ്രക്രിയകൾ, പ്രോത്സാഹനങ്ങൾ. ("DevOps പാഠങ്ങൾ: ആരോഗ്യകരമായ പരീക്ഷണങ്ങളുടെ 4 വശങ്ങൾ" എന്ന ഗോർഡൻ ഹഫിൻ്റെ ലേഖനത്തിൽ നിങ്ങൾക്ക് ഈ ഘടകങ്ങളെ കുറിച്ച് കൂടുതൽ വായിക്കാം.)

4. മുന്നോട്ടുള്ള പാത വൃത്തിയാക്കുക

ബെൻ ഗ്രിനെൽ, മാനേജിംഗ് ഡയറക്ടറും കൺസൾട്ടൻസി നോർത്ത് ഹൈലാൻഡിലെ ഡിജിറ്റൽ മേധാവിയും: “സ്കെയിൽ നേടുന്നതിന്, പയനിയറിംഗ് പ്രോജക്റ്റുകൾക്കൊപ്പം ഒരു “പാത്ത് ക്ലിയറിംഗ്” പ്രോഗ്രാം സമാരംഭിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു. ഈ പ്രോഗ്രാമിൻ്റെ ലക്ഷ്യം, കാലഹരണപ്പെട്ട നിയമങ്ങളും അതുപോലുള്ള കാര്യങ്ങളും പോലെ, DevOps പയനിയർമാർ ഉപേക്ഷിക്കുന്ന മാലിന്യങ്ങൾ വൃത്തിയാക്കുക എന്നതാണ്, അതുവഴി മുന്നോട്ടുള്ള പാത വ്യക്തമാകും.

“പുതിയ പ്രവർത്തന രീതികളുടെ വിജയങ്ങൾ വ്യാപകമായി ആഘോഷിച്ചുകൊണ്ട് പയനിയറിംഗ് ഗ്രൂപ്പിന് അപ്പുറത്തേക്ക് പോകുന്ന ആശയവിനിമയത്തിലൂടെ ആളുകൾക്ക് സംഘടനാപരമായ പിന്തുണയും വേഗതയും നൽകുക. DevOps പ്രോജക്റ്റുകളുടെ അടുത്ത തരംഗത്തിൽ ഏർപ്പെട്ടിരിക്കുന്നവരും ആദ്യമായി DevOps ഉപയോഗിക്കുന്നതിൽ പരിഭ്രാന്തരായ ആളുകളെയും പരിശീലിപ്പിക്കുക. ഈ ആളുകൾ പയനിയർമാരിൽ നിന്ന് വളരെ വ്യത്യസ്തരാണെന്ന് ഓർക്കുക.

5. ടൂളുകളെ ജനാധിപത്യവൽക്കരിക്കുക

സ്‌കലിറിൻ്റെ സ്ഥാപകനും ചെയർമാനുമായ സ്റ്റീവ് ന്യൂമാൻ: “ഉപകരണങ്ങൾ ആളുകളിൽ നിന്ന് മറച്ചുവെക്കരുത്, സമയം ചെലവഴിക്കാൻ തയ്യാറുള്ള ആർക്കും പഠിക്കാൻ താരതമ്യേന എളുപ്പമുള്ളതായിരിക്കണം. ലോഗുകൾ അന്വേഷിക്കാനുള്ള കഴിവ് ഒരു ടൂൾ ഉപയോഗിക്കുന്നതിന് "സർട്ടിഫൈഡ്" ഉള്ള മൂന്ന് ആളുകൾക്ക് മാത്രമായി പരിമിതപ്പെടുത്തിയിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് വളരെ വലിയ കമ്പ്യൂട്ടിംഗ് പരിതസ്ഥിതി ഉണ്ടെങ്കിൽ പോലും, പ്രശ്നം കൈകാര്യം ചെയ്യാൻ നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും പരമാവധി മൂന്ന് ആളുകളെ മാത്രമേ ലഭ്യമാകൂ. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഗുരുതരമായ (ബിസിനസ്) പ്രത്യാഘാതങ്ങളിലേക്ക് നയിച്ചേക്കാവുന്ന ഒരു തടസ്സമുണ്ട്.

6. ടീം വർക്കിന് അനുയോജ്യമായ സാഹചര്യങ്ങൾ സൃഷ്ടിക്കുക

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

7. കോൺവേയുടെ നിയമത്തെക്കുറിച്ചും കാൻബൻ ബോർഡുകളെക്കുറിച്ചും മറക്കരുത്

ലോഗൻ ഡെയ്ഗൽ, CollabNetVersionOne-ലെ സോഫ്റ്റ്‌വെയർ ഡെലിവറി, DevOps സ്ട്രാറ്റജി ഡയറക്ടർ: “കോൺവേയുടെ നിയമത്തിൻ്റെ അനന്തരഫലങ്ങൾ മനസ്സിലാക്കേണ്ടത് പ്രധാനമാണ്. എൻ്റെ അയഞ്ഞ പദപ്രയോഗത്തിൽ, DevOps ഉൾപ്പെടെ, ഞങ്ങൾ സൃഷ്‌ടിക്കുന്ന ഉൽപ്പന്നങ്ങളും അതിനായി ഉപയോഗിക്കുന്ന പ്രക്രിയകളും ഞങ്ങളുടെ ഓർഗനൈസേഷൻ്റെ അതേ രീതിയിൽ ഘടനാപരമായതായി മാറുമെന്ന് ഈ നിയമം പ്രസ്‌താവിക്കുന്നു.

“ഒരു ഓർഗനൈസേഷനിൽ ധാരാളം സിലോകൾ ഉണ്ടെങ്കിൽ, സോഫ്‌റ്റ്‌വെയർ ആസൂത്രണം ചെയ്യുമ്പോഴും നിർമ്മിക്കുമ്പോഴും റിലീസ് ചെയ്യുമ്പോഴും നിയന്ത്രണം പലതവണ മാറുകയാണെങ്കിൽ, സ്കെയിലിംഗിൻ്റെ പ്രഭാവം പൂജ്യമോ ഹ്രസ്വകാലമോ ആയിരിക്കും. മാർക്കറ്റ് ഫോക്കസ് ഉപയോഗിച്ച് ഫണ്ട് ചെയ്യുന്ന ഉൽപ്പന്നങ്ങൾക്ക് ചുറ്റും ഒരു ഓർഗനൈസേഷൻ ക്രോസ്-ഫംഗ്ഷണൽ ടീമുകളെ നിർമ്മിക്കുകയാണെങ്കിൽ, വിജയസാധ്യത ഗണ്യമായി വർദ്ധിക്കുന്നു.

“സ്കെയിലിംഗിൻ്റെ മറ്റൊരു പ്രധാന വശം കാൻബൻ ബോർഡുകളിൽ പുരോഗതിയിലുള്ള എല്ലാ ജോലികളും (WIP, workinprogress) പ്രദർശിപ്പിക്കുക എന്നതാണ്. ആളുകൾക്ക് ഈ കാര്യങ്ങൾ കാണാൻ കഴിയുന്ന ഒരു സ്ഥാപനത്തിന് ഒരു സ്ഥലമുണ്ടെങ്കിൽ, അത് സഹകരണത്തെ വളരെയധികം പ്രോത്സാഹിപ്പിക്കുന്നു, അത് സ്കെയിലിംഗിൽ നല്ല സ്വാധീനം ചെലുത്തുന്നു.

8. പഴയ പാടുകൾ നോക്കുക

മാനുവൽ പൈസ്, DevOps കൺസൾട്ടൻ്റും ടീം ടോപ്പോളജീസിൻ്റെ സഹ-രചയിതാവും: “Dev, Ops എന്നിവയ്‌ക്കപ്പുറം DevOps പ്രാക്ടീസുകൾ എടുക്കുകയും അവ മറ്റ് ഫംഗ്ഷനുകളിൽ പ്രയോഗിക്കാൻ ശ്രമിക്കുകയും ചെയ്യുന്നത് ഒരു മികച്ച സമീപനമല്ല. ഇത് തീർച്ചയായും ചില സ്വാധീനം ചെലുത്തും (ഉദാഹരണത്തിന്, സ്വമേധയാലുള്ള നിയന്ത്രണം ഓട്ടോമേറ്റ് ചെയ്യുന്നതിലൂടെ), എന്നാൽ ഡെലിവറി, ഫീഡ്‌ബാക്ക് പ്രക്രിയകൾ മനസ്സിലാക്കി തുടങ്ങിയാൽ കൂടുതൽ കാര്യങ്ങൾ നേടാനാകും.

“ഒരു ഓർഗനൈസേഷൻ്റെ ഐടി സിസ്റ്റത്തിൽ പഴയ പാടുകൾ ഉണ്ടെങ്കിൽ - മുൻകാല സംഭവങ്ങളുടെ ഫലമായി നടപ്പിലാക്കിയ നടപടിക്രമങ്ങളും മാനേജ്മെൻ്റ് മെക്കാനിസങ്ങളും എന്നാൽ അവയുടെ പ്രസക്തി നഷ്ടപ്പെട്ടു (ഉൽപ്പന്നങ്ങൾ, സാങ്കേതികവിദ്യകൾ അല്ലെങ്കിൽ പ്രക്രിയകൾ എന്നിവയിലെ മാറ്റങ്ങൾ കാരണം) - അവ തീർച്ചയായും നീക്കം ചെയ്യേണ്ടതുണ്ട്. അല്ലെങ്കിൽ കാര്യക്ഷമമല്ലാത്തതോ അനാവശ്യമോ ആയ പ്രക്രിയകൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനുപകരം സുഗമമാക്കുക.

9. DevOps ഓപ്ഷനുകൾ വളർത്തരുത്

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

10. DevOps-ൻ്റെ ബിസിനസ്സ് മൂല്യം പ്രസംഗിക്കുക

സ്‌കലിറിൻ്റെ സ്ഥാപകനും ചെയർമാനുമായ സ്റ്റീവ് ന്യൂമാൻ: “DevOps-ൻ്റെ മൂല്യം തിരിച്ചറിയാൻ പ്രവർത്തിക്കുക. നിങ്ങൾ ചെയ്യുന്നതിൻ്റെ നേട്ടങ്ങളെക്കുറിച്ച് പഠിക്കുക, സംസാരിക്കാൻ മടിക്കേണ്ടതില്ല. DevOps ഒരു അവിശ്വസനീയമായ സമയവും പണവും ലാഭിക്കുന്നതാണ് (ചിന്തിക്കുക: പ്രവർത്തനരഹിതമായ സമയം, വീണ്ടെടുക്കാനുള്ള കുറഞ്ഞ ശരാശരി സമയം), ബിസിനസ്സ് വിജയത്തിനുള്ള ഈ സംരംഭങ്ങളുടെ പ്രാധാന്യം DevOps ടീമുകൾ അശ്രാന്തമായി ഊന്നിപ്പറയുകയും (പ്രസംഗിക്കുകയും വേണം). ഇതുവഴി നിങ്ങൾക്ക് അനുയായികളുടെ സർക്കിൾ വികസിപ്പിക്കാനും സ്ഥാപനത്തിൽ DevOps-ൻ്റെ സ്വാധീനം വർദ്ധിപ്പിക്കാനും കഴിയും.

ബോണസ്

ഓൺ റെഡ് ഹാറ്റ് ഫോറം റഷ്യ ഞങ്ങളുടെ സ്വന്തം DevOps സെപ്റ്റംബർ 13-ന് എത്തും - അതെ, ഒരു സോഫ്റ്റ്‌വെയർ നിർമ്മാതാവ് എന്ന നിലയിൽ Red Hat-ന് അതിൻ്റേതായ DevOps ടീമുകളും പരിശീലനങ്ങളും ഉണ്ട്.

ഓർഗനൈസേഷനിലുടനീളം മറ്റ് ഗ്രൂപ്പുകൾക്കായി ആന്തരിക ഓട്ടോമേഷൻ സേവനങ്ങൾ വികസിപ്പിച്ചെടുക്കുന്ന ഞങ്ങളുടെ എഞ്ചിനീയർ മാർക്ക് ബിർഗർ, ശുദ്ധമായ റഷ്യൻ ഭാഷയിൽ സ്വന്തം കഥ പറയും - Ansible നിയന്ത്രിക്കുന്ന ഒരു പൂർണ്ണമായ കണ്ടെയ്നർ ഫോർമാറ്റിലേക്ക് Red Hat DevOps ടീം എങ്ങനെയാണ് ആപ്ലിക്കേഷനുകൾ മൈഗ്രേറ്റ് ചെയ്തത്. OpenShift പ്ലാറ്റ്ഫോം.

എന്നാൽ അത് മാത്രമല്ല:

ഓർഗനൈസേഷനുകൾ ജോലിഭാരം കണ്ടെയ്‌നറുകളിലേക്ക് മാറ്റിക്കഴിഞ്ഞാൽ, പരമ്പരാഗത ആപ്ലിക്കേഷൻ മോണിറ്ററിംഗ് രീതികൾ പ്രവർത്തിച്ചേക്കില്ല. രണ്ടാമത്തെ സംഭാഷണത്തിൽ, ഞങ്ങൾ ലോഗിൻ ചെയ്യുന്ന രീതി മാറ്റുന്നതിനുള്ള ഞങ്ങളുടെ പ്രചോദനം വിശദീകരിക്കുകയും ആധുനിക ലോഗിംഗ്, മോണിറ്ററിംഗ് രീതികളിലേക്ക് ഞങ്ങളെ നയിച്ച പാതയുടെ തുടർച്ച കാണിക്കുകയും ചെയ്യും.

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