DevOps എഞ്ചിനീയർമാരില്ല. അപ്പോൾ ആരാണ് നിലനിൽക്കുന്നത്, അത് എന്തുചെയ്യണം?

അടുത്തിടെ, അത്തരം പരസ്യങ്ങൾ ഇന്റർനെറ്റിൽ നിറഞ്ഞു. സന്തോഷകരമായ ശമ്പളം ഉണ്ടായിരുന്നിട്ടും, ഉള്ളിൽ വന്യമായ പാഷണ്ഡത എഴുതിയിരിക്കുന്നതിൽ ലജ്ജിക്കാതിരിക്കാൻ കഴിയില്ല. "DevOps", "എഞ്ചിനീയർ" എന്നിവ എങ്ങനെയെങ്കിലും ഒരു വാക്കിൽ ഒട്ടിക്കാൻ കഴിയുമെന്ന് ആദ്യം അനുമാനിക്കപ്പെടുന്നു, തുടർന്ന് ആവശ്യകതകളുടെ ക്രമരഹിതമായ ഒരു ലിസ്റ്റ് ഉണ്ട്, അവയിൽ ചിലത് sysadmin ഒഴിവുകളിൽ നിന്ന് വ്യക്തമായി പകർത്തിയിരിക്കുന്നു.

ഈ പോസ്റ്റിൽ, നമ്മൾ എങ്ങനെ ഈ ജീവിതത്തിലേക്ക് എത്തി, DevOps യഥാർത്ഥത്തിൽ എന്താണ്, അത് ഇപ്പോൾ എന്തുചെയ്യണം എന്നതിനെക്കുറിച്ച് കുറച്ച് സംസാരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

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

സംസ്കാരത്തെയും പ്രക്രിയകളെയും കുറിച്ച്

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

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

"സഖാക്കൾക്കിടയിൽ യോജിപ്പില്ലാത്തപ്പോൾ
അവർക്ക് കാര്യങ്ങൾ നന്നായി നടക്കില്ല,
അതിൽ നിന്ന് ഒന്നും പുറത്തുവരില്ല, പീഡനം മാത്രം.
ഒരിക്കൽ ഒരു സ്വാൻ, ഒരു കൊഞ്ച്, ഒരു പൈക്ക് ... "

വെബ് പ്രോഗ്രാമർമാരുടെ ഏത് ഭാഗമാണ് അവരുടെ ആപ്ലിക്കേഷനുകൾ ഉൽപ്പാദനത്തിൽ ഉപയോഗിക്കുന്നതെന്ന് ശരിക്കും മനസ്സിലാക്കുമെന്ന് നിങ്ങൾ കരുതുന്നു? ഇവരിൽ എത്ര പേർ അഡ്മിൻമാരുടെ അടുത്ത് പോയി ഡാറ്റാബേസ് തകരാറിലായാൽ എന്ത് സംഭവിക്കുമെന്ന് മനസിലാക്കാൻ ശ്രമിക്കും? അവരിൽ ആരാണ് പരീക്ഷകരുടെ അടുത്ത് പോയി പരീക്ഷകൾ ശരിയായി എഴുതുന്നത് എങ്ങനെയെന്ന് പഠിപ്പിക്കാൻ അവരോട് ആവശ്യപ്പെടും? കൂടാതെ സെക്യൂരിറ്റി ഗാർഡുകൾ, ഉൽപ്പന്ന മാനേജർമാർ, കൂടാതെ ഒരു കൂട്ടം ആളുകൾ എന്നിവരും ഉണ്ട്.

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

കഷ്ട കാലം

"ഡെവോപ്സ് എഞ്ചിനീയറിംഗ്" എന്ന അച്ചടക്കം എവിടെ നിന്നാണ് വന്നത്? ഞങ്ങൾക്ക് ഒരു പതിപ്പുണ്ട്! DevOps ആശയങ്ങൾ മികച്ചതായിരുന്നു - വളരെ മികച്ചതായിരുന്നു, അവർ സ്വന്തം വിജയത്തിന്റെ ഇരകളായി. സ്വന്തമായ അന്തരീക്ഷമുള്ള ചില നിഴൽ റിക്രൂട്ടർമാരും മനുഷ്യക്കടത്തുകാരും ഈ വിഷയത്തെ മുഴുവൻ ചുറ്റിക്കറങ്ങാൻ തുടങ്ങി.

സങ്കൽപ്പിക്കുക: ഇന്നലെ നിങ്ങൾ ഖിംകിയിൽ ഷവർമ ഉണ്ടാക്കുകയായിരുന്നു, ഇന്ന് നിങ്ങൾ ഇതിനകം ഒരു വലിയ മനുഷ്യനാണ്, ഒരു മുതിർന്ന റിക്രൂട്ടർ ആണ്. സ്ഥാനാർത്ഥികളെ തിരയുന്നതിനും തിരഞ്ഞെടുക്കുന്നതിനുമുള്ള ഒരു മുഴുവൻ പ്രക്രിയയും ഉണ്ട്, എല്ലാം എളുപ്പമല്ല, നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്. ഒരു ഡിപ്പാർട്ട്മെന്റിന്റെ തലവൻ പറയുന്നു: X-ൽ ഒരു സ്പെഷ്യലിസ്റ്റിനെ കണ്ടെത്തുക. ഞങ്ങൾ "എഞ്ചിനീയർ" എന്ന വാക്ക് X- ലേക്ക് നിയോഗിക്കുന്നു, ഞങ്ങൾ പൂർത്തിയാക്കി. Linux വേണോ? ശരി, ഇത് തീർച്ചയായും ഒരു Linux എഞ്ചിനീയറാണ്, നിങ്ങൾക്ക് DevOps വേണമെങ്കിൽ, ഒരു DevOps എഞ്ചിനീയർ. ഒഴിവിൽ ഒരു ശീർഷകം മാത്രമല്ല, ചില വാചകങ്ങളും ഉള്ളിൽ നൽകണം. നിങ്ങളുടെ ഭാവനയെ ആശ്രയിച്ച് Google-ൽ നിന്നുള്ള ഒരു കൂട്ടം കീവേഡുകൾ നൽകുക എന്നതാണ് ഏറ്റവും എളുപ്പമുള്ള മാർഗം. DevOps-ൽ രണ്ട് വാക്കുകൾ അടങ്ങിയിരിക്കുന്നു - "ദേവ്", "ഓപ്‌സ്", അതിനർത്ഥം ഡെവലപ്പർമാരുമായും അഡ്മിനിസ്ട്രേറ്റർമാരുമായും ബന്ധപ്പെട്ട കീവേഡുകൾ ഒരുമിച്ച് ഒട്ടിക്കുക, എല്ലാം ഒരു കൂമ്പാരമായി. 42 പ്രോഗ്രാമിംഗ് ഭാഷകളിലെ പ്രാവീണ്യത്തെക്കുറിച്ചും 20 വർഷത്തെ കുബർനെറ്റസും സ്വാമും ഒരേസമയം ഉപയോഗിക്കുന്നതിനെക്കുറിച്ചും ഒഴിവുകൾ പ്രത്യക്ഷപ്പെടുന്നത് ഇങ്ങനെയാണ്. പ്രവർത്തന ഡയഗ്രം.

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

ഡിമാൻഡ് സപ്ലൈ സൃഷ്ടിക്കുന്നു, കൂടാതെ ഈ ട്രാഷ് ഒഴിവുകളെല്ലാം ഭ്രാന്തമായ നിരവധി സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാരാൽ നികത്തപ്പെട്ടിരിക്കുന്നു: നിങ്ങൾക്ക് എല്ലാം പഴയതുപോലെ ചെയ്യാൻ കഴിയും, എന്നാൽ സ്വയം "ഡെവോപ്സ്" എന്ന് വിളിക്കുന്നതിലൂടെ നിരവധി തവണ കൂടുതൽ നേടുക. നിങ്ങൾ ഒരു സമയം എസ്എസ്എച്ച് വഴി സെർവറുകൾ സ്വമേധയാ കോൺഫിഗർ ചെയ്തതുപോലെ, നിങ്ങൾ അവ കോൺഫിഗർ ചെയ്യുന്നത് തുടരും, എന്നാൽ ഇപ്പോൾ ഇതൊരു devops പ്രാക്ടീസ് ആണെന്ന് കരുതുന്നു. ഇത് ഒരുതരം സങ്കീർണ്ണമായ പ്രതിഭാസമാണ്, ഇത് ക്ലാസിക് അഡ്‌മിനുകളെ കുറച്ചുകാണുന്നതും DevOps-നെ ചുറ്റിപ്പറ്റിയുള്ള ഹൈപ്പുമായി ഭാഗികമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, എന്നാൽ പൊതുവേ, സംഭവിച്ചത് സംഭവിച്ചു.

അതിനാൽ ഞങ്ങൾക്ക് വിതരണവും ആവശ്യവും ഉണ്ട്. സ്വയം പോറ്റുന്ന ഒരു ദുഷിച്ച വൃത്തം. ഇതിനെതിരെയാണ് ഞങ്ങൾ പോരാടുന്നത് (DevOops കോൺഫറൻസ് സൃഷ്ടിക്കുന്നത് ഉൾപ്പെടെ).

തീർച്ചയായും, "devops" എന്ന് സ്വയം പുനർനാമകരണം ചെയ്ത സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർക്ക് പുറമെ മറ്റ് പങ്കാളികളും ഉണ്ട് - ഉദാഹരണത്തിന്, പ്രൊഫഷണൽ SRE-കൾ അല്ലെങ്കിൽ ഇൻഫ്രാസ്ട്രക്ചർ-ആസ്-കോഡ് ഡെവലപ്പർമാർ.

DevOps-ൽ ആളുകൾ എന്താണ് ചെയ്യുന്നത് (ശരിക്കും)

അതിനാൽ DevOps പ്രാക്ടീസുകൾ പഠിക്കുന്നതിലും പ്രയോഗിക്കുന്നതിലും നിങ്ങൾ മുന്നേറാൻ ആഗ്രഹിക്കുന്നു. എന്നാൽ ഇത് എങ്ങനെ ചെയ്യണം, ഏത് ദിശയിലാണ് നോക്കേണ്ടത്? വ്യക്തമായും, നിങ്ങൾ ജനപ്രിയ കീവേഡുകളെ അന്ധമായി ആശ്രയിക്കരുത്.

ജോലിയുണ്ടെങ്കിൽ ആരെങ്കിലും ചെയ്യണം. ഇവർ “ഡെവോപ്സ് എഞ്ചിനീയർമാർ” അല്ലെന്ന് ഞങ്ങൾ ഇതിനകം കണ്ടെത്തി, അപ്പോൾ ആരാണ്? സ്ഥാനങ്ങളുടെ അടിസ്ഥാനത്തിലല്ല, ജോലിയുടെ പ്രത്യേക മേഖലകളുടെ അടിസ്ഥാനത്തിൽ ഇത് രൂപപ്പെടുത്തുന്നത് കൂടുതൽ ശരിയാണെന്ന് തോന്നുന്നു.

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

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

പ്രശ്നത്തിന്റെ ഒരു സാങ്കേതിക ഭാഗവുമുണ്ട്, തീർച്ചയായും. നിങ്ങളുടെ പുതിയ കോഡ് ഒരു മാസത്തിനുള്ളിൽ പരീക്ഷിക്കപ്പെടുകയും ഒരു വർഷത്തിന് ശേഷം മാത്രമേ പുറത്തിറങ്ങുകയും ചെയ്യുകയുള്ളൂവെങ്കിൽ, അത് വേഗത്തിലാക്കുന്നത് ശാരീരികമായി അസാധ്യമാണെങ്കിൽ, നിങ്ങൾ നല്ല സമ്പ്രദായങ്ങൾ പാലിക്കണമെന്നില്ല. നല്ല രീതികൾ നല്ല ഉപകരണങ്ങൾ പിന്തുണയ്ക്കുന്നു. ഉദാഹരണത്തിന്, ഇൻഫ്രാസ്ട്രക്ചർ-ആസ്-കോഡ് എന്ന ആശയം മനസ്സിൽ വെച്ചുകൊണ്ട്, നിങ്ങൾക്ക് AWS CloudFormation, Terraform മുതൽ Chef-Ansible-Puppet വരെ എന്തും ഉപയോഗിക്കാം. നിങ്ങൾക്ക് ഇതെല്ലാം അറിയുകയും ചെയ്യാൻ കഴിയുകയും വേണം, ഇത് ഇതിനകം തന്നെ ഒരു എഞ്ചിനീയറിംഗ് അച്ചടക്കമാണ്. കാരണം ഫലവുമായി ആശയക്കുഴപ്പത്തിലാക്കാതിരിക്കേണ്ടത് പ്രധാനമാണ്: ആദ്യം നിങ്ങൾ എസ്ആർഇയുടെ തത്വങ്ങൾക്കനുസൃതമായി പ്രവർത്തിക്കുന്നു, അതിനുശേഷം മാത്രമേ ഈ തത്ത്വങ്ങൾ ചില പ്രത്യേക സാങ്കേതിക പരിഹാരങ്ങളുടെ രൂപത്തിൽ നടപ്പിലാക്കൂ. അതേ സമയം, SRE എന്നത് വളരെ സമഗ്രമായ ഒരു രീതിശാസ്ത്രമാണ്, അത് Jenkins എങ്ങനെ സജ്ജീകരിക്കാമെന്ന് നിങ്ങളോട് പറയുന്നില്ല, എന്നാൽ ഏകദേശം അഞ്ച് അടിസ്ഥാന തത്വങ്ങൾ:

• റോളുകളും വകുപ്പുകളും തമ്മിലുള്ള ആശയവിനിമയം മെച്ചപ്പെടുത്തി
• ജോലിയുടെ അവിഭാജ്യ ഘടകമായി തെറ്റുകൾ സ്വീകരിക്കുക
• ക്രമേണ മാറ്റങ്ങൾ വരുത്തുന്നു
• ടൂളിംഗും മറ്റ് ഓട്ടോമേഷനും ഉപയോഗിക്കുന്നു
• അളക്കാൻ കഴിയുന്നതെല്ലാം അളക്കുന്നു

ഇത് ഒരു കൂട്ടം പ്രസ്താവനകൾ മാത്രമല്ല, ഒരു പ്രത്യേക കാര്യമാണ് പ്രവർത്തനത്തിലേക്കുള്ള വഴികാട്ടി. ഉദാഹരണത്തിന്, പിശകുകൾ സ്വീകരിക്കുന്നതിനുള്ള പാതയിൽ, നിങ്ങൾ അപകടസാധ്യതകൾ മനസിലാക്കേണ്ടതുണ്ട്, SLI (SLI) പോലെയുള്ള എന്തെങ്കിലും ഉപയോഗിച്ച് സേവനങ്ങളുടെ ലഭ്യതയും ലഭ്യതയും അളക്കേണ്ടതുണ്ട്.സേവന നില സൂചകങ്ങൾ) കൂടാതെ SLO (സേവന തലത്തിലുള്ള ലക്ഷ്യങ്ങൾ), പോസ്റ്റ്‌മോർട്ടം എഴുതാനും അവ എഴുതുന്നത് ഭയപ്പെടുത്താതിരിക്കാനും പഠിക്കുക.

SRE അച്ചടക്കത്തിൽ, ഉപകരണങ്ങളുടെ ഉപയോഗം പ്രധാനപ്പെട്ട ഒന്നാണെങ്കിലും വിജയത്തിന്റെ ഒരു ഭാഗം മാത്രമാണ്. നമ്മൾ നിരന്തരം സാങ്കേതികമായി വികസിപ്പിക്കേണ്ടതുണ്ട്, ലോകത്ത് എന്താണ് സംഭവിക്കുന്നതെന്ന് നോക്കുക, അത് നമ്മുടെ ജോലിയിൽ എങ്ങനെ പ്രയോഗിക്കാം.

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

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

ഇതൊക്കെ എന്ത് ചെയ്യണം

ഓരോരുത്തരും ഈ പ്രശ്നങ്ങൾ അവരുടേതായ രീതിയിൽ പരിഹരിക്കുന്നു: ഉദാഹരണത്തിന്, ദൂഷിത വലയം തകർക്കാൻ നിങ്ങൾക്ക് സാധാരണ ഒഴിവുകൾ പ്രസിദ്ധീകരിക്കാൻ കഴിയും. DevOps, ക്ലൗഡ് നേറ്റീവ് തുടങ്ങിയ പദങ്ങൾ എന്താണ് അർത്ഥമാക്കുന്നത് എന്ന് നിങ്ങൾക്ക് കണ്ടെത്താനും അവ കൃത്യമായി ഉപയോഗിക്കാനും കഴിയും. നിങ്ങൾക്ക് DevOps-ൽ വികസിപ്പിക്കാനും നിങ്ങളുടെ ഉദാഹരണത്തിലൂടെ ശരിയായ സമീപനങ്ങൾ പ്രകടിപ്പിക്കാനും കഴിയും.

ഞങ്ങൾ ഒരു സമ്മേളനം നടത്തുകയാണ് DevOops 2020 മോസ്കോ, ഞങ്ങൾ ഇപ്പോൾ സംസാരിച്ച കാര്യങ്ങളിൽ കൂടുതൽ ആഴത്തിൽ പരിശോധിക്കാൻ ഇത് അവസരം നൽകുന്നു. ഇതിനായി നിരവധി ഗ്രൂപ്പുകളുടെ റിപ്പോർട്ടുകളുണ്ട്:

• പ്രക്രിയകളും സംസ്കാരവും;
• സൈറ്റ് വിശ്വാസ്യത എഞ്ചിനീയറിംഗ്;
• ക്ലൗഡ് നേറ്റീവ്;

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

വ്യക്തമായും, കോൺഫറൻസിൽ തന്നെ നിങ്ങൾക്ക് ഒരേസമയം മൂന്ന് ട്രാക്കുകളിൽ പോകാൻ കഴിയില്ല, അതിനാൽ ഓരോ ടൈം സ്ലോട്ടിലും ഓരോ അഭിരുചിക്കും വിഷയങ്ങൾ ഉള്ള വിധത്തിൽ ഞങ്ങൾ പ്രോഗ്രാം സംഘടിപ്പിക്കുന്നു.

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

• അടിസ്ഥാന സൗകര്യങ്ങളിൽ പ്രവർത്തിക്കുന്ന ഡെവലപ്പർമാർ. SRE, Cloud Native എന്നിവയെ കുറിച്ചുള്ള റിപ്പോർട്ടുകളുടെ ഗ്രൂപ്പുകൾ നിങ്ങൾക്ക് ഏറ്റവും അനുയോജ്യമാണ്.
• സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർ. ഇവിടെ കൂടുതൽ സങ്കീർണ്ണമാണ്. DevOops എന്നത് സിസ്റ്റം അഡ്മിനിസ്ട്രേഷനല്ല. ഭാഗ്യവശാൽ, സിസ്റ്റം അഡ്മിനിസ്ട്രേഷൻ എന്ന വിഷയത്തിൽ ധാരാളം മികച്ച കോൺഫറൻസുകൾ, പുസ്തകങ്ങൾ, ലേഖനങ്ങൾ, ഇന്റർനെറ്റിൽ വീഡിയോകൾ മുതലായവ ഉണ്ട്. മറുവശത്ത്, സംസ്കാരവും പ്രക്രിയകളും മനസ്സിലാക്കുന്നതിനും ക്ലൗഡ് സാങ്കേതികവിദ്യകളെ കുറിച്ചും ക്ലൗഡ് നേറ്റീവിനൊപ്പം ജീവിതത്തിന്റെ വിശദാംശങ്ങളെ കുറിച്ചും പഠിക്കുന്നതിൽ നിങ്ങൾ സ്വയം വികസിപ്പിക്കാൻ താൽപ്പര്യമുണ്ടെങ്കിൽ, നിങ്ങളെ കാണാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു! ഇതിനെക്കുറിച്ച് ചിന്തിക്കുക: നിങ്ങൾ ഭരണം നടത്തുകയാണ്, അപ്പോൾ നിങ്ങൾ എന്ത് ചെയ്യും? പെട്ടെന്ന് അസുഖകരമായ ഒരു സാഹചര്യത്തിൽ സ്വയം കണ്ടെത്തുന്നത് ഒഴിവാക്കാൻ, നിങ്ങൾ ഇപ്പോൾ പഠിക്കണം.

മറ്റൊരു ഓപ്ഷൻ ഉണ്ട്: നിങ്ങൾ തുടരുകയും നിങ്ങളാണെന്ന് അവകാശപ്പെടുന്നത് തുടരുകയും ചെയ്യുന്നു പ്രത്യേകിച്ച് ഒരു DevOps എഞ്ചിനീയർ മറ്റൊന്നുമല്ല, അതിന്റെ അർത്ഥം എന്തായാലും. അപ്പോൾ ഞങ്ങൾ നിങ്ങളെ നിരാശരാക്കേണ്ടതുണ്ട്, DevOops DevOps എഞ്ചിനീയർമാർക്കുള്ള ഒരു കോൺഫറൻസല്ല!

നിന്ന് സ്ലൈഡ് ചെയ്യുക കോൺസ്റ്റാന്റിൻ ഡൈനറുടെ റിപ്പോർട്ട് മ്യൂണിക്കിൽ

DevOops 2020 മോസ്കോ ഏപ്രിൽ 29-30 തീയതികളിൽ മോസ്കോയിൽ നടക്കും, ടിക്കറ്റുകൾ ഇതിനകം ലഭ്യമാണ് ഔദ്യോഗിക വെബ്സൈറ്റിൽ വാങ്ങുക.

പകരമായി, നിങ്ങൾക്ക് കഴിയും നിങ്ങളുടെ റിപ്പോർട്ട് സമർപ്പിക്കുക ഫെബ്രുവരി 8 വരെ. ഫോം പൂരിപ്പിക്കുമ്പോൾ, നിങ്ങളുടെ റിപ്പോർട്ടിൽ നിന്ന് കൂടുതൽ പ്രയോജനം ലഭിക്കുന്ന ടാർഗെറ്റ് പ്രേക്ഷകരെ നിങ്ങൾ തിരഞ്ഞെടുക്കണം എന്നത് ശ്രദ്ധിക്കുക (ലിസ്റ്റിനുള്ളിൽ ഒരു അത്ഭുതം മറഞ്ഞിരിക്കുന്നു).

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