എന്താണ് DevOps

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

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

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

മറ്റ് കാര്യങ്ങളിൽ, ഞാൻ DevOps മോസ്കോ കമ്മ്യൂണിറ്റിയുടെ സംഘാടകരിലൊരാളും DevOps-Days 2017 ന്റെ സംഘാടകനുമാണ്, പക്ഷേ ഞാൻ 2018 സംഘടിപ്പിച്ചില്ല. എക്സ്പ്രസ് 42 നിരവധി കമ്പനികളുമായി പ്രവർത്തിക്കുന്നു. ഞങ്ങൾ അവിടെ DevOps വളർത്തുന്നു, അത് എങ്ങനെ സംഭവിക്കുന്നുവെന്ന് കാണുക, നിഗമനങ്ങളിൽ എത്തിച്ചേരുക, വിശകലനം ചെയ്യുക, ഞങ്ങളുടെ നിഗമനങ്ങൾ എല്ലാവരോടും പറയുക, DevOps പരിശീലനങ്ങളിൽ ആളുകളെ പരിശീലിപ്പിക്കുക. പൊതുവേ, ഇക്കാര്യത്തിൽ ഞങ്ങളുടെ അനുഭവവും വൈദഗ്ധ്യവും വർദ്ധിപ്പിക്കുന്നതിന് ഞങ്ങൾ പരമാവധി ശ്രമിക്കുന്നു.

എന്തുകൊണ്ട് DevOps

എല്ലാവരെയും എപ്പോഴും വേട്ടയാടുന്ന ആദ്യത്തെ ചോദ്യം - എന്തുകൊണ്ട്? DevOps വെറും ഓട്ടോമേഷൻ അല്ലെങ്കിൽ എല്ലാ കമ്പനികൾക്കും ഇതിനകം ഉണ്ടായിരുന്ന സമാന കാര്യമാണെന്ന് പലരും കരുതുന്നു.

— ഞങ്ങൾക്ക് തുടർച്ചയായ സംയോജനം ഉണ്ടായിരുന്നു - ഇതിനർത്ഥം ഞങ്ങൾക്ക് ഇതിനകം DevOps ഉണ്ടായിരുന്നു, എന്തുകൊണ്ടാണ് ഈ സ്റ്റഫ് എല്ലാം ആവശ്യമായിരിക്കുന്നത്? അവർ വിദേശത്ത് ആസ്വദിക്കുന്നു, പക്ഷേ അവർ ഞങ്ങളെ ജോലി ചെയ്യുന്നതിൽ നിന്ന് തടയുന്നു!

കമ്മ്യൂണിറ്റിയുടെയും മെത്തഡോളജിയുടെയും 9 വർഷത്തെ വികസനം, ഇത് ഇപ്പോഴും മാർക്കറ്റിംഗ് ഗ്ലിറ്റർ അല്ലെന്ന് ഇതിനകം വ്യക്തമായിട്ടുണ്ട്, എന്നാൽ ഇത് എന്തിനാണ് ആവശ്യമെന്ന് ഇപ്പോഴും പൂർണ്ണമായും വ്യക്തമല്ല. ഏതൊരു ഉപകരണത്തെയും പ്രക്രിയയെയും പോലെ, DevOps-ന് അത് ആത്യന്തികമായി കൈവരിക്കുന്ന നിർദ്ദിഷ്ട ലക്ഷ്യങ്ങളുണ്ട്.

ലോകം മാറിക്കൊണ്ടിരിക്കുന്ന വസ്തുതയാണ് ഇതിനെല്ലാം കാരണം. കമ്പനികൾ ഒരു സ്വപ്നത്തിലേക്ക് നേരെ നീങ്ങുമ്പോൾ, ഞങ്ങളുടെ സെന്റ് പീറ്റേഴ്‌സ്ബർഗ് ക്ലാസിക് പാടിയതുപോലെ, ഒരു നിശ്ചിത തന്ത്രമനുസരിച്ച് പോയിന്റ് എ മുതൽ പോയിന്റ് ബി വരെ, ഇതിനായി നിർമ്മിച്ച ഒരു നിശ്ചിത ഘടനയുമായി അദ്ദേഹം എന്റർപ്രൈസ് സമീപനത്തിൽ നിന്ന് അകന്നുപോകുന്നു.

തത്വത്തിൽ, ഐടിയിലെ എല്ലാം ഈ സമീപനം അനുസരിച്ച് നിർമ്മിക്കണം. ഇവിടെ IT പ്രക്രിയകൾ ഓട്ടോമേറ്റ് ചെയ്യാൻ മാത്രമായി ഉപയോഗിക്കുന്നു.

ഓട്ടോമേഷൻ പലപ്പോഴും മാറില്ല, കാരണം ഒരു കമ്പനി നന്നായി ചവിട്ടിയരക്കുമ്പോൾ, എന്താണ് മാറ്റേണ്ടത്? ഇത് പ്രവർത്തിക്കുന്നു - അതിൽ തൊടരുത്. ഇപ്പോൾ ലോകത്തിലെ സമീപനങ്ങൾ മാറിക്കൊണ്ടിരിക്കുന്നു, എജൈൽ എന്ന് വിളിക്കപ്പെടുന്ന ഒന്ന് സൂചിപ്പിക്കുന്നത് അവസാന പോയിന്റ് ബി ഉടനടി ദൃശ്യമാകില്ല എന്നാണ്.

ഒരു കമ്പനി വിപണിയിലൂടെ കടന്നുപോകുമ്പോൾ, ഒരു ക്ലയന്റുമായി പ്രവർത്തിക്കുമ്പോൾ, അത് നിരന്തരം വിപണി പര്യവേക്ഷണം ചെയ്യുകയും അവസാന പോയിന്റ് ബി മാറ്റുകയും ചെയ്യുന്നു. മാത്രമല്ല, കമ്പനി കൂടുതൽ തവണ അതിന്റെ ദിശ മാറ്റുന്നു, അവസാനം അത് കൂടുതൽ വിജയകരമാകും, കാരണം അത് കൂടുതൽ വിപണി തിരഞ്ഞെടുക്കുന്നു. മാടം.

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

ഈ ഉൽപ്പന്നം 1 ബില്യൺ ഡോളറിന് യൂണിലിവർ വാങ്ങി. ഇത് ഇപ്പോൾ ഗില്ലറ്റുമായി മത്സരിക്കുകയും അമേരിക്കൻ വിപണിയിലെ ഉപഭോക്താക്കളുടെ ഗണ്യമായ പങ്ക് അപഹരിക്കുകയും ചെയ്തു. വൺ ബോക്സ് ഷേവ് പറയുന്നു:

- 4 ബ്ലേഡുകൾ? നിങ്ങൾ ഗൗരവത്തിലാണോ? നിങ്ങൾക്ക് ഇത് എന്തിന് ആവശ്യമാണ് - ഇത് ഷേവിംഗിന്റെ ഗുണനിലവാരം മെച്ചപ്പെടുത്തുന്നില്ല. പ്രത്യേകം തിരഞ്ഞെടുത്ത ക്രീം, സുഗന്ധം, രണ്ട് ബ്ലേഡുകളുള്ള ഉയർന്ന നിലവാരമുള്ള റേസർ എന്നിവ ആ മണ്ടൻ 4 ഗില്ലറ്റ് ബ്ലേഡുകളേക്കാൾ കൂടുതൽ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നു! ഞങ്ങൾ ഉടൻ 10-ൽ എത്തുമോ?

ലോകം മാറുന്നത് ഇങ്ങനെയാണ്. ഇത് ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു അടിപൊളി ഐടി സിസ്റ്റം തങ്ങൾക്കുണ്ടെന്ന് യൂണിലിവർ അവകാശപ്പെടുന്നു. അവസാനം ഒരു സങ്കൽപ്പം പോലെ തോന്നുന്നു സമയം-ടു-വിപണി, ആരും ഇതിനകം സംസാരിച്ചിട്ടില്ല.

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

ടൈം-ടു-മാർക്കറ്റ് എന്നത് ആശയം മുതൽ അന്തിമ നിർവ്വഹണം വരെയുള്ള സമയം കുറയ്ക്കലാണ്.

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

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

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

1968-ൽ, മെൽവിൻ കോൺവേ എന്ന ദീർഘവീക്ഷണമുള്ള ഒരു വ്യക്തി ഇനിപ്പറയുന്ന ആശയം രൂപപ്പെടുത്തി.

സിസ്റ്റം സൃഷ്ടിക്കുന്ന ഓർഗനൈസേഷൻ, ആ ഓർഗനൈസേഷന്റെ ആശയവിനിമയ ഘടനയെ ആവർത്തിക്കുന്ന ഒരു രൂപകൽപ്പനയാൽ പരിമിതപ്പെടുത്തിയിരിക്കുന്നു.

കൂടുതൽ വിശദമായി പറഞ്ഞാൽ, മറ്റൊരു തരത്തിലുള്ള സിസ്റ്റങ്ങൾ നിർമ്മിക്കുന്നതിന്, മറ്റൊരു തരത്തിലുള്ള കമ്പനിക്കുള്ളിൽ നിങ്ങൾക്ക് ഒരു ആശയവിനിമയ ഘടനയും ഉണ്ടായിരിക്കണം. നിങ്ങളുടെ ആശയവിനിമയ ഘടന ഉയർന്ന ശ്രേണിയിലുള്ളതാണെങ്കിൽ, വളരെ ഉയർന്ന ടൈം-ടു-മാർക്കറ്റ് ഇൻഡിക്കേറ്റർ നൽകാൻ കഴിയുന്ന സിസ്റ്റങ്ങൾ സൃഷ്ടിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കില്ല.

വായിക്കുക കോൺവേയുടെ നിയമത്തെക്കുറിച്ച് can ലിങ്കുകൾ വഴി. DevOps സംസ്കാരം അല്ലെങ്കിൽ തത്ത്വചിന്ത മനസ്സിലാക്കുന്നതിന് ഇത് പ്രധാനമാണ് DevOps-ൽ അടിസ്ഥാനപരമായി മാറുന്ന ഒരേയൊരു കാര്യം ടീമുകൾ തമ്മിലുള്ള ആശയവിനിമയത്തിന്റെ ഘടനയാണ്.

ഒരു പ്രോസസ് പോയിന്റിൽ, DevOps-ന് മുമ്പ്, എല്ലാ ഘട്ടങ്ങളും: വിശകലനം, വികസനം, പരിശോധന, പ്രവർത്തനം, രേഖീയമായിരുന്നു.
DevOps-ന്റെ കാര്യത്തിൽ, ഈ പ്രക്രിയകളെല്ലാം ഒരേസമയം സംഭവിക്കുന്നു.

ടൈം-ടു-മാർക്കറ്റ് മാത്രമാണ് ഇത് ചെയ്യാൻ കഴിയുന്ന ഏക മാർഗം. പഴയ പ്രക്രിയയിൽ പ്രവർത്തിച്ച ആളുകൾക്ക്, ഇത് അൽപ്പം കോസ്മിക് ആയി കാണപ്പെടുന്നു, പൊതുവെ അങ്ങനെയാണ്.

എന്തുകൊണ്ടാണ് നിങ്ങൾക്ക് DevOps വേണ്ടത്?

ഡിജിറ്റൽ ഉൽപ്പന്ന വികസനത്തിന്. നിങ്ങളുടെ കമ്പനിക്ക് ഒരു ഡിജിറ്റൽ ഉൽപ്പന്നം ഇല്ലെങ്കിൽ, DevOps ആവശ്യമില്ല - ഇത് വളരെ പ്രധാനമാണ്.

DevOps തുടർച്ചയായ സോഫ്റ്റ്‌വെയർ നിർമ്മാണത്തിന്റെ വേഗത പരിമിതികളെ മറികടക്കുന്നു. അതിൽ എല്ലാ പ്രക്രിയകളും ഒരേസമയം സംഭവിക്കുന്നു.

ബുദ്ധിമുട്ട് വർദ്ധിക്കുന്നു. സോഫ്റ്റ്‌വെയർ പുറത്തിറക്കുന്നത് എളുപ്പമാക്കുമെന്ന് DevOps സുവിശേഷകർ നിങ്ങളോട് പറയുമ്പോൾ, ഇത് അസംബന്ധമാണ്.

DevOps ഉപയോഗിച്ച്, കാര്യങ്ങൾ കൂടുതൽ സങ്കീർണ്ണമാകും.

Avito സ്റ്റാൻഡിലെ കോൺഫറൻസിൽ, ഒരു ഡോക്കർ കണ്ടെയ്നർ വിന്യസിക്കുന്നത് എങ്ങനെയാണെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും - ഒരു യാഥാർത്ഥ്യബോധമില്ലാത്ത ജോലി. സങ്കീർണ്ണത നിരോധിതമായിത്തീരുന്നു; നിങ്ങൾ ഒരേ സമയം നിരവധി പന്തുകൾ കൈകാര്യം ചെയ്യേണ്ടതുണ്ട്.

DevOps കമ്പനിയിലെ പ്രക്രിയയും ഓർഗനൈസേഷനും പൂർണ്ണമായും മാറ്റുന്നു — കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, മാറുന്നത് DevOps അല്ല, ഡിജിറ്റൽ ഉൽപ്പന്നമാണ്. DevOps-ലേക്ക് വരാൻ, നിങ്ങൾ ഇപ്പോഴും ഈ പ്രക്രിയ പൂർണ്ണമായും മാറ്റേണ്ടതുണ്ട്.

ഒരു സ്പെഷ്യലിസ്റ്റിനുള്ള ചോദ്യങ്ങൾ

നിങ്ങൾക്ക് എന്താണ് ഉള്ളത്? ഒരു കമ്പനിയിൽ ജോലി ചെയ്യുമ്പോഴും ഒരു സ്പെഷ്യലിസ്റ്റായി വികസിപ്പിക്കുമ്പോഴും നിങ്ങൾക്ക് സ്വയം ചോദിക്കാൻ കഴിയുന്ന ചോദ്യങ്ങൾ.

ഒരു ഡിജിറ്റൽ ഉൽപ്പന്നം സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു തന്ത്രം നിങ്ങൾക്കുണ്ടോ? ഉണ്ടെങ്കിൽ, അത് ഇതിനകം നല്ലതാണ്. നിങ്ങളുടെ കമ്പനി DevOps-ലേക്ക് നീങ്ങുന്നു എന്നാണ് ഇതിനർത്ഥം.

നിങ്ങളുടെ കമ്പനി ഇതിനകം ഒരു ഡിജിറ്റൽ ഉൽപ്പന്നം സൃഷ്ടിക്കുന്നുണ്ടോ? ഇതിനർത്ഥം നിങ്ങൾക്ക് മറ്റൊരു ലെവൽ ഉയരാനും കൂടുതൽ രസകരമായി കാര്യങ്ങൾ ചെയ്യാനും കഴിയുമെന്നാണ് - വീണ്ടും ഒരു DevOps വീക്ഷണകോണിൽ നിന്ന്. ഈ കാഴ്ചപ്പാടിൽ നിന്ന് മാത്രമാണ് ഞാൻ സംസാരിക്കുന്നത്.

നിങ്ങളുടെ കമ്പനി ഡിജിറ്റൽ ഉൽപ്പന്നങ്ങളുടെ വിപണിയിലെ പ്രമുഖരിൽ ഒരാളാണോ? Spotify, Yandex, Uber എന്നിവ ഇപ്പോൾ സാങ്കേതിക പുരോഗതിയുടെ കൊടുമുടിയിൽ നിൽക്കുന്ന കമ്പനികളാണ്.

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

സംഘടന

ഞാൻ പറഞ്ഞതുപോലെ, കോൺവേയുടെ നിയമമനുസരിച്ച്, ഒരു കമ്പനിയുടെ ഓർഗനൈസേഷൻ മാറുന്നു. ഓർഗനൈസേഷണൽ വീക്ഷണകോണിൽ നിന്ന് DevOps കമ്പനിക്കുള്ളിൽ തുളച്ചുകയറുന്നതിൽ നിന്ന് തടയുന്നത് ഞാൻ ആരംഭിക്കും.

"കിണറുകളുടെ" പ്രശ്നം

"Silo" എന്ന ഇംഗ്ലീഷ് വാക്ക് ഇവിടെ റഷ്യൻ ഭാഷയിലേക്ക് "well" എന്നാണ് വിവർത്തനം ചെയ്തിരിക്കുന്നത്. ഈ പ്രശ്നത്തിന്റെ കാര്യം അതാണ് ടീമുകൾക്കിടയിൽ വിവരങ്ങൾ കൈമാറുന്നില്ല. നാവിഗേറ്റ് ചെയ്യുന്നതിനായി ഒരു പൊതു ഭൂപടം നിർമ്മിക്കാതെ ഓരോ ടീമും അതിന്റെ വൈദഗ്ദ്ധ്യം ആഴത്തിൽ കുഴിക്കുന്നു.

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

ഈ വഴിതെറ്റിയ നിമിഷത്തെ മറികടക്കാൻ DevOps നിർദ്ദേശിക്കുന്നു, ഒരു പൊതു ഇന്ററാക്ഷൻ മാപ്പ് നിർമ്മിക്കാൻ എല്ലാ വകുപ്പുകളും ഒരുമിച്ച് പ്രവർത്തിക്കുന്നു.

രണ്ട് ഘടകങ്ങൾ ഇതിന് തടസ്സമാകുന്നു.

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

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

- ഞങ്ങൾ CI സമാരംഭിക്കാൻ ആഗ്രഹിച്ചു, പക്ഷേ മാനേജ്മെന്റിന് അത് ആവശ്യമില്ലെന്ന് മനസ്സിലായി.

കാരണം ഇത് കൃത്യമായി സംഭവിക്കുന്നു CI и തുടർച്ചയായ ഡെലിവറി പ്രക്രിയ നിരവധി പരീക്ഷകളുടെ അതിർത്തിയിലാണ്. സംഘടനാ തലത്തിൽ "കിണർ" എന്ന പ്രശ്നം മറികടക്കാതെ, നിങ്ങൾ എന്ത് ചെയ്താലും എത്ര സങ്കടപ്പെട്ടാലും നിങ്ങൾക്ക് മുന്നോട്ട് പോകാൻ കഴിയില്ല.

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

ആളുകൾ ചില നക്ഷത്രങ്ങൾക്കോ ​​പതാകകൾക്കോ ​​വേണ്ടി പോരാടുന്നു, എല്ലാവരും അവരുടെ വൈദഗ്ധ്യം കുഴിക്കുന്നു.

തൽഫലമായി, ഇതെല്ലാം ഒരുമിച്ച് ബന്ധിപ്പിച്ച് ഒരു പൊതു പൈപ്പ്ലൈൻ നിർമ്മിക്കാനുള്ള ചുമതല ഉണ്ടാകുമ്പോൾ, ഇനി നക്ഷത്രങ്ങൾക്കും പതാകകൾക്കും വേണ്ടി പോരാടേണ്ട ആവശ്യമില്ല, ചോദ്യം ഉയർന്നുവരുന്നു - എന്തായാലും എന്തുചെയ്യണം? എങ്ങനെയെങ്കിലും ഒത്തുതീർപ്പിലെത്തണം, പക്ഷേ ഇത് എങ്ങനെ ചെയ്യണമെന്ന് ആരും ഞങ്ങളെ സ്കൂളിൽ പഠിപ്പിച്ചില്ല. സ്കൂൾ മുതൽ ഞങ്ങൾ പഠിപ്പിച്ചു: എട്ടാം ക്ലാസ് - കൊള്ളാം! - ഏഴാം ക്ലാസുമായി താരതമ്യം ചെയ്യുമ്പോൾ! ഇവിടെയും അങ്ങനെ തന്നെ.

നിങ്ങളുടെ കമ്പനിയിലും ഇത് തന്നെയാണോ?

ഇത് പരിശോധിക്കുന്നതിന്, നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന ചോദ്യങ്ങൾ സ്വയം ചോദിക്കാവുന്നതാണ്.

ടീമുകൾ പൊതുവായ ടൂളുകൾ ഉപയോഗിക്കുകയും ആ പൊതു ഉപകരണങ്ങളിൽ മാറ്റങ്ങൾ വരുത്താൻ സംഭാവന നൽകുകയും ചെയ്യുന്നുണ്ടോ?

എത്ര തവണ ടീമുകൾ പുനഃസംഘടിപ്പിക്കും - ഒരു ടീമിൽ നിന്നുള്ള ചില സ്പെഷ്യലിസ്റ്റുകൾ മറ്റൊരു ടീമിലേക്ക് മാറുന്നു? ഒരു DevOps പരിതസ്ഥിതിയിലാണ് ഇത് സാധാരണമാകുന്നത്, കാരണം ചിലപ്പോൾ ഒരു വ്യക്തിക്ക് മറ്റൊരു വൈദഗ്ധ്യം എന്താണ് ചെയ്യുന്നതെന്ന് മനസിലാക്കാൻ കഴിയില്ല. അവൻ മറ്റൊരു ഡിപ്പാർട്ട്‌മെന്റിലേക്ക് മാറുന്നു, രണ്ടാഴ്ചയോളം അവിടെ പ്രവർത്തിക്കുകയും ഈ ഡിപ്പാർട്ട്‌മെന്റുമായുള്ള ഓറിയന്റേഷന്റെയും ഇടപഴകലിന്റെയും ഒരു മാപ്പ് സൃഷ്‌ടിക്കുകയും ചെയ്യുന്നു.

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

കമ്പനിയുടെ നേട്ടങ്ങൾ പരിഗണിക്കാതെ മാനേജർമാർക്ക് വ്യക്തിഗത നേട്ടങ്ങൾ ലഭിക്കുന്നത് എത്ര പ്രധാനമാണ്?

ഈ ചോദ്യങ്ങൾക്ക് നിങ്ങൾ സ്വയം ഉത്തരം നൽകിയാൽ, നിങ്ങളുടെ കമ്പനിയിൽ നിങ്ങൾക്ക് അത്തരമൊരു പ്രശ്നമുണ്ടോ എന്ന് വ്യക്തമാകും.

അടിസ്ഥാന സൗകര്യങ്ങൾ കോഡായി

ഈ പ്രശ്നം പാസാക്കിയ ശേഷം, DevOps-ൽ കൂടുതൽ മുന്നേറാൻ ബുദ്ധിമുട്ടുള്ള ആദ്യത്തെ പ്രധാന സമ്പ്രദായം ഇതാണ് അടിസ്ഥാന സൗകര്യങ്ങൾ കോഡായി.

മിക്കപ്പോഴും, ഇൻഫ്രാസ്ട്രക്ചർ കോഡായി ഇനിപ്പറയുന്ന രീതിയിൽ മനസ്സിലാക്കുന്നു:

— നമുക്ക് ബാഷിൽ എല്ലാം ഓട്ടോമേറ്റ് ചെയ്യാം, സ്ക്രിപ്റ്റുകൾ കൊണ്ട് സ്വയം മറയ്ക്കാം, അങ്ങനെ അഡ്മിൻമാർക്ക് മാനുവൽ വർക്ക് കുറവാണ്!

എന്നാൽ അത് സത്യമല്ല.

കോഡ് എന്ന നിലയിൽ ഇൻഫ്രാസ്ട്രക്ചർ എന്നതിനർത്ഥം നിങ്ങൾ പ്രവർത്തിക്കുന്ന ഐടി സിസ്റ്റത്തെ അതിന്റെ അവസ്ഥ നിരന്തരം മനസ്സിലാക്കുന്നതിനായി കോഡിന്റെ രൂപത്തിൽ വിവരിക്കുന്നു എന്നാണ്.

മറ്റ് ടീമുകൾക്കൊപ്പം, എല്ലാവർക്കും മനസ്സിലാക്കാൻ കഴിയുന്നതും നാവിഗേറ്റ് ചെയ്യാനും നാവിഗേറ്റ് ചെയ്യാനുമുള്ള കോഡിന്റെ രൂപത്തിൽ നിങ്ങൾ ഒരു മാപ്പ് സൃഷ്ടിക്കുന്നു. ഷെഫ്, അൻസിബിൾ, ഉപ്പ്, അല്ലെങ്കിൽ കുബെർനെറ്റസിലെ YAML ഫയലുകൾ ഉപയോഗിക്കുന്നത് - ഇത് എന്തിലാണ് ചെയ്തതെന്നത് പ്രശ്നമല്ല.

കോൺഫറൻസിൽ, 2GIS-ൽ നിന്നുള്ള ഒരു സഹപ്രവർത്തകൻ കുബെർനെറ്റസിനായി അവരുടെ സ്വന്തം ആന്തരിക കാര്യം എങ്ങനെ ഉണ്ടാക്കി എന്ന് പറഞ്ഞു, അത് വ്യക്തിഗത സിസ്റ്റങ്ങളുടെ ഘടനയെ വിവരിക്കുന്നു. 500 സിസ്റ്റങ്ങളെ വിവരിക്കാൻ, അവർക്ക് ഈ വിവരണം സൃഷ്ടിക്കുന്ന ഒരു പ്രത്യേക ഉപകരണം ആവശ്യമാണ്. ഈ വിവരണം ഉള്ളപ്പോൾ, എല്ലാവർക്കും പരസ്പരം പരിശോധിക്കാനും മാറ്റങ്ങൾ നിരീക്ഷിക്കാനും അത് എങ്ങനെ മാറ്റാം, മെച്ചപ്പെടുത്താം, എന്താണ് നഷ്‌ടമായത്.

സമ്മതിക്കുന്നു, വ്യക്തിഗത ബാഷ് സ്ക്രിപ്റ്റുകൾ സാധാരണയായി ഈ ധാരണ നൽകുന്നില്ല. ഞാൻ ജോലി ചെയ്തിരുന്ന ഒരു കമ്പനിയിൽ, "എഴുതാൻ മാത്രം" എന്ന സ്ക്രിപ്റ്റിന് ഒരു പേര് പോലും ഉണ്ടായിരുന്നു - സ്ക്രിപ്റ്റ് എഴുതുമ്പോൾ, പക്ഷേ അത് ഇനി വായിക്കാൻ കഴിയില്ല. ഇത് നിങ്ങൾക്കും പരിചിതമാണെന്ന് ഞാൻ കരുതുന്നു.

കോഡ് പോലെ അടിസ്ഥാന സൗകര്യങ്ങൾ അടിസ്ഥാന സൗകര്യങ്ങളുടെ നിലവിലെ അവസ്ഥ വിവരിക്കുന്ന കോഡ്. നിരവധി ഉൽപ്പന്നങ്ങൾ, ഇൻഫ്രാസ്ട്രക്ചർ, സേവന ടീമുകൾ ഈ കോഡിൽ ഒരുമിച്ച് പ്രവർത്തിക്കുന്നു, ഏറ്റവും പ്രധാനമായി, ഈ കോഡ് യഥാർത്ഥത്തിൽ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് അവരെല്ലാം മനസ്സിലാക്കേണ്ടതുണ്ട്.

മികച്ച കോഡ് സമ്പ്രദായങ്ങൾക്കനുസൃതമായാണ് കോഡ് പരിപാലിക്കുന്നത്: സംയുക്ത വികസനം, കോഡ് അവലോകനം, എക്സ്പി-പ്രോഗ്രാമിംഗ്, ടെസ്റ്റിംഗ്, പുൾ അഭ്യർത്ഥനകൾ, കോഡ് ഇൻഫ്രാസ്ട്രക്ചറുകൾക്കുള്ള CI - ഇതെല്ലാം അനുയോജ്യവും ഉപയോഗിക്കാൻ കഴിയുന്നതുമാണ്.

കോഡ് എല്ലാ എഞ്ചിനീയർമാർക്കും ഒരു പൊതു ഭാഷയായി മാറുന്നു.

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

പ്രധാനപ്പെട്ട: നിങ്ങൾ ഇതുവരെ ഈ സ്റ്റഫ് പരീക്ഷിച്ചിട്ടില്ലെങ്കിൽ, അത് ഓർക്കുക അൻസിബിൾ ബാഷ് അല്ല! ഡോക്യുമെന്റേഷൻ ശ്രദ്ധാപൂർവ്വം വായിക്കുക, അതിനെക്കുറിച്ച് അവർ എന്താണ് എഴുതുന്നതെന്ന് പഠിക്കുക.

ഇൻഫ്രാസ്ട്രക്ചർ കോഡ് എന്ന നിലയിൽ ഇൻഫ്രാസ്ട്രക്ചർ കോഡിനെ പ്രത്യേക പാളികളായി വേർതിരിക്കുന്നതാണ്.

ഞങ്ങളുടെ കമ്പനിയിൽ, ഞങ്ങൾ 3 അടിസ്ഥാന ലെയറുകളെ വേർതിരിക്കുന്നു, അവ വളരെ വ്യക്തവും ലളിതവുമാണ്, എന്നാൽ അവയിൽ കൂടുതൽ ഉണ്ടായിരിക്കാം. നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ കോഡ് നോക്കി നിങ്ങൾക്ക് ഈ അവസ്ഥ ഉണ്ടോ ഇല്ലയോ എന്ന് പറയാം. ലെയറുകളൊന്നും ഹൈലൈറ്റ് ചെയ്തിട്ടില്ലെങ്കിൽ, നിങ്ങൾ കുറച്ച് സമയമെടുത്ത് കുറച്ച് റീഫാക്റ്റർ ചെയ്യേണ്ടതുണ്ട്.


അടിസ്ഥാന പാളി - ഇങ്ങനെയാണ് OS, ബാക്കപ്പുകൾ, മറ്റ് താഴ്ന്ന നിലയിലുള്ള കാര്യങ്ങൾ എന്നിവ ക്രമീകരിച്ചിരിക്കുന്നത്, ഉദാഹരണത്തിന്, അടിസ്ഥാന തലത്തിൽ Kubernetes എങ്ങനെയാണ് വിന്യസിച്ചിരിക്കുന്നത്.

സേവന നില - ഇവയാണ് നിങ്ങൾ ഡെവലപ്പർക്ക് നൽകുന്ന സേവനങ്ങൾ: ഒരു സേവനമായി ലോഗിംഗ്, ഒരു സേവനമായി നിരീക്ഷിക്കൽ, ഒരു സേവനമായി ഡാറ്റാബേസ്, ഒരു സേവനമായി ബാലൻസർ, ഒരു സേവനമായി ക്യൂ, ഒരു സേവനമായി തുടർച്ചയായ ഡെലിവറി - വ്യക്തിഗത ടീമുകൾ നൽകുന്ന സേവനങ്ങളുടെ ഒരു കൂട്ടം വികസനത്തിന് നൽകാൻ കഴിയും. ഇതെല്ലാം നിങ്ങളുടെ കോൺഫിഗറേഷൻ മാനേജ്‌മെന്റ് സിസ്റ്റത്തിലെ പ്രത്യേക മൊഡ്യൂളുകളിൽ വിവരിക്കേണ്ടതുണ്ട്.

ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്ന പാളി മുമ്പത്തെ രണ്ട് പാളികൾക്ക് മുകളിൽ അവ എങ്ങനെ വികസിക്കുമെന്ന് വിവരിക്കുന്നു.

ചോദ്യങ്ങൾ നിയന്ത്രിക്കുക

നിങ്ങളുടെ കമ്പനിക്ക് ഒരു പൊതു ഇൻഫ്രാസ്ട്രക്ചർ റിപ്പോസിറ്ററി ഉണ്ടോ? നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിലെ സാങ്കേതിക കടം നിങ്ങൾ കൈകാര്യം ചെയ്യുന്നുണ്ടോ? ഒരു ഇൻഫ്രാസ്ട്രക്ചർ റിപ്പോസിറ്ററിയിൽ നിങ്ങൾ വികസന രീതികൾ ഉപയോഗിക്കുന്നുണ്ടോ? നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ പാളികളായി മുറിച്ചിട്ടുണ്ടോ? നിങ്ങൾക്ക് Base-service-APP ഡയഗ്രം പരിശോധിക്കാം. ഒരു മാറ്റം വരുത്തുന്നത് എത്ര ബുദ്ധിമുട്ടാണ്?

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

തുടർച്ചയായ ഡെലിവറി

ഡെബിറ്റ് ക്രെഡിറ്റുമായി താരതമ്യം ചെയ്യാം. അടിസ്ഥാന സൗകര്യങ്ങളുടെ ഒരു വിവരണം ആദ്യം വരുന്നു, അത് തികച്ചും അടിസ്ഥാനപരമായിരിക്കും. നിങ്ങൾ എല്ലാം വിശദമായി വിവരിക്കേണ്ടതില്ല, എന്നാൽ ചില അടിസ്ഥാന വിവരണം ആവശ്യമായതിനാൽ നിങ്ങൾക്ക് ഇത് ഉപയോഗിച്ച് പ്രവർത്തിക്കാനാകും. അല്ലെങ്കിൽ, തുടർച്ചയായ ഡെലിവറി അടുത്തതായി എന്തുചെയ്യണമെന്ന് വ്യക്തമല്ല. നിങ്ങൾ DevOps-ലേക്ക് വരുമ്പോൾ ഈ രീതികളെല്ലാം ഒരേസമയം വികസിക്കുന്നു, എന്നാൽ നിങ്ങളുടെ പക്കലുള്ളത് എന്താണെന്നും അത് എങ്ങനെ കൈകാര്യം ചെയ്യാമെന്നും മനസ്സിലാക്കുന്നതിലൂടെയാണ് ഇത് ആരംഭിക്കുന്നത്. അടിസ്ഥാന സൗകര്യങ്ങളെ കോഡായി കണക്കാക്കുന്നത് ഇതാണ്.

നിങ്ങൾക്കത് ഉണ്ടെന്നും അത് എങ്ങനെ കൈകാര്യം ചെയ്യാമെന്നും വ്യക്തമായിക്കഴിഞ്ഞാൽ, ഡവലപ്പർ കോഡ് എങ്ങനെ കഴിയുന്നത്ര വേഗത്തിൽ ഉൽപ്പാദനത്തിലേക്ക് അയയ്ക്കാമെന്ന് നിങ്ങൾ കണ്ടുപിടിക്കാൻ തുടങ്ങും. ഡവലപ്പറുമായി ചേർന്നാണ് ഞാൻ ഉദ്ദേശിക്കുന്നത് - “കിണറുകളുടെ” പ്രശ്നത്തെക്കുറിച്ച് ഞങ്ങൾ ഓർക്കുന്നു, അതായത്, ഇത് കൊണ്ടുവരുന്നത് വ്യക്തിഗത ആളുകളല്ല, മറിച്ച് ഒരു ടീമാണ്.

നമ്മൾ കൂടെയുള്ളപ്പോൾ വന്യ എവ്തുഖോവിച്ച് ആദ്യ പുസ്തകം കണ്ടു ജെസ് വിനയം രചയിതാക്കളുടെ ഗ്രൂപ്പുകളും "തുടർച്ചയുള്ള ഡെലിവറി", 2009-ൽ പുറത്തിറങ്ങിയ, അതിന്റെ തലക്കെട്ട് റഷ്യൻ ഭാഷയിലേക്ക് എങ്ങനെ വിവർത്തനം ചെയ്യാമെന്ന് ഞങ്ങൾ വളരെക്കാലമായി ചിന്തിച്ചു. അവർ അതിനെ "സ്ഥിരമായി വിതരണം ചെയ്യുക" എന്ന് വിവർത്തനം ചെയ്യാൻ ആഗ്രഹിച്ചു, പക്ഷേ, നിർഭാഗ്യവശാൽ, അത് "തുടർച്ചയായ ഡെലിവറി" എന്ന് വിവർത്തനം ചെയ്യപ്പെട്ടു. ഞങ്ങളുടെ പേരിൽ സമ്മർദത്തോടെ എന്തോ റഷ്യൻ ഉണ്ടെന്ന് എനിക്ക് തോന്നുന്നു.

നിരന്തരം വിതരണം ചെയ്യുന്ന മാർഗങ്ങൾ

ഉൽപ്പന്ന സംഭരണിയിൽ ഉള്ള കോഡ് എപ്പോഴും പ്രൊഡക്ഷനിലേക്ക് ഡൗൺലോഡ് ചെയ്യാം. അവൻ നിരാശനാകില്ലായിരിക്കാം, പക്ഷേ അവൻ എപ്പോഴും അതിന് തയ്യാറാണ്. അതനുസരിച്ച്, നിങ്ങളുടെ ടെയിൽബോണിന് താഴെയുള്ള ചില ഉത്കണ്ഠകൾ വിശദീകരിക്കാൻ പ്രയാസമുള്ള വികാരത്തോടെയാണ് നിങ്ങൾ എപ്പോഴും കോഡ് എഴുതുന്നത്. നിങ്ങൾ ഇൻഫ്രാസ്ട്രക്ചർ കോഡ് പുറത്തിറക്കുമ്പോൾ ഇത് പലപ്പോഴും ദൃശ്യമാകും. ചില ഉത്കണ്ഠയുടെ ഈ തോന്നൽ ഉണ്ടായിരിക്കണം - ഇത് മസ്തിഷ്ക പ്രക്രിയകളെ ട്രിഗർ ചെയ്യുന്നു, അത് നിങ്ങളെ കോഡ് വ്യത്യസ്തമായി എഴുതാൻ അനുവദിക്കുന്നു. വികസനത്തിനുള്ളിലെ നിയമങ്ങളിൽ ഇത് രേഖപ്പെടുത്തണം.

സ്ഥിരമായി ഡെലിവർ ചെയ്യുന്നതിന്, നിങ്ങൾക്ക് ഒരു ഇൻഫ്രാസ്ട്രക്ചർ പ്ലാറ്റ്‌ഫോമിൽ ഉടനീളം പ്രവർത്തിക്കുന്ന ഒരു ആർട്ടിഫാക്‌റ്റ് ഫോർമാറ്റ് ആവശ്യമാണ്. നിങ്ങൾ ഒരു ഇൻഫ്രാസ്ട്രക്ചർ പ്ലാറ്റ്‌ഫോമിലുടനീളം വ്യത്യസ്ത ഫോർമാറ്റുകളുടെ "ജീവിത മാലിന്യങ്ങൾ" എറിയുകയാണെങ്കിൽ, അത് ഏകീകൃതമാകും, പരിപാലിക്കാൻ പ്രയാസമാണ്, സാങ്കേതിക കടത്തിന്റെ പ്രശ്നം ഉയർന്നുവരുന്നു. ആർട്ടിഫാക്‌റ്റിന്റെ ഫോർമാറ്റ് വിന്യസിക്കേണ്ടതുണ്ട് - ഇതും ഒരു കൂട്ടായ ദൗത്യമാണ്: നാമെല്ലാവരും ഒത്തുചേരുകയും തലച്ചോറിനെ തുരത്തുകയും ഈ ഫോർമാറ്റ് കൊണ്ടുവരികയും വേണം.

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

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

വ്യത്യസ്ത വിന്യാസ തന്ത്രങ്ങൾ. ഉദാഹരണത്തിന്, വ്യത്യസ്‌ത ക്ലയന്റുകളിൽ കോഡ് വ്യത്യസ്‌തമായി പരിശോധിക്കുന്നതിനും കോഡ് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ നേടുന്നതിനും 100 ദശലക്ഷം ഉപയോക്താക്കൾക്ക് ഇത് ലഭ്യമാക്കിയതിനേക്കാൾ വളരെ മുമ്പേയ്‌ക്കും നിങ്ങൾ എബി പരിശോധനയോ കാനറി വിന്യാസമോ ഉപയോഗിക്കുന്നു.

"സ്ഥിരമായി വിതരണം" ഇതുപോലെ കാണപ്പെടുന്നു.

ഡെലിവറി പ്രക്രിയ Dev, CI, Test, PreProd, Prod എന്നിവ ഒരു പ്രത്യേക പരിതസ്ഥിതിയല്ല, ഇവ നിങ്ങളുടെ പുരാവസ്തു കടന്നുപോകുന്ന ഫയർപ്രൂഫ് തുകകളുള്ള സ്റ്റേജുകളോ സ്റ്റേഷനുകളോ ആണ്.

നിങ്ങൾക്ക് അടിസ്ഥാന സേവന APP എന്ന് വിവരിച്ചിരിക്കുന്ന ഇൻഫ്രാസ്ട്രക്ചർ കോഡ് ഉണ്ടെങ്കിൽ അത് സഹായിക്കുന്നു എല്ലാ സ്ക്രിപ്റ്റുകളും മറക്കരുത്, ഈ പുരാവസ്തുവിന്റെ കോഡായി അവ എഴുതുക, പുരാവസ്തു പ്രോത്സാഹിപ്പിക്കുക നിങ്ങൾ പോകുമ്പോൾ അത് മാറ്റുക.

സ്വയം പരിശോധനാ ചോദ്യങ്ങൾ

ഫീച്ചർ വിവരണത്തിൽ നിന്ന് 95% കേസുകളിലും പ്രൊഡക്ഷനിലേക്ക് റിലീസ് ചെയ്യാനുള്ള സമയം ഒരാഴ്ചയിൽ താഴെയാണോ? പൈപ്പ് ലൈനിന്റെ ഓരോ ഘട്ടത്തിലും പുരാവസ്തുവിന്റെ ഗുണനിലവാരം മെച്ചപ്പെടുമോ? അതിലൂടെ കടന്നുപോകുന്ന ഒരു കഥയുണ്ടോ? നിങ്ങൾ വ്യത്യസ്ത വിന്യാസ തന്ത്രങ്ങൾ ഉപയോഗിക്കുന്നുണ്ടോ?

എല്ലാ ഉത്തരങ്ങളും അതെ എന്നാണെങ്കിൽ, നിങ്ങൾ അവിശ്വസനീയമാംവിധം ശാന്തനാണ്! അഭിപ്രായങ്ങളിൽ നിങ്ങളുടെ ഉത്തരങ്ങൾ എഴുതുക - ഞാൻ സന്തോഷിക്കും).

ഫീഡ്ബാക്ക്

ഇതാണ് ഏറ്റവും പ്രയാസമേറിയ സമ്പ്രദായം. DevOpsConf കോൺഫറൻസിൽ, Infobip-ൽ നിന്നുള്ള ഒരു സഹപ്രവർത്തകൻ, അതിനെക്കുറിച്ച് സംസാരിക്കുമ്പോൾ, അദ്ദേഹത്തിന്റെ വാക്കുകളിൽ അൽപ്പം ആശയക്കുഴപ്പമുണ്ടായി, കാരണം നിങ്ങൾ എല്ലാം നിരീക്ഷിക്കേണ്ടതുണ്ട് എന്ന വസ്തുതയെക്കുറിച്ചുള്ള വളരെ സങ്കീർണ്ണമായ ഒരു പരിശീലനമാണിത്!

ഉദാഹരണത്തിന്, വളരെക്കാലം മുമ്പ്, ഞാൻ ക്വിക്കിൽ ജോലി ചെയ്തപ്പോൾ, എല്ലാം നിരീക്ഷിക്കേണ്ടതുണ്ടെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി. ഞങ്ങൾ ഇത് ചെയ്തു, ഇപ്പോൾ Zabbix-ൽ 150 ഇനങ്ങൾ ഉണ്ട്, അവ നിരന്തരം നിരീക്ഷിക്കപ്പെടുന്നു. ഇത് ഭയാനകമായിരുന്നു, ടെക്നിക്കൽ ഡയറക്ടർ തന്റെ ക്ഷേത്രത്തിലേക്ക് വിരൽ വളച്ചു:

- സുഹൃത്തുക്കളേ, നിങ്ങൾ എന്തിനാണ് അവ്യക്തമായ എന്തെങ്കിലും ഉപയോഗിച്ച് സെർവറിനെ ബലാത്സംഗം ചെയ്യുന്നത്?

എന്നാൽ ഇത് ശരിക്കും വളരെ രസകരമായ ഒരു തന്ത്രമാണെന്ന് കാണിക്കുന്ന ഒരു സംഭവം സംഭവിച്ചു.

സർവീസുകളിലൊന്ന് നിരന്തരം തകരാറിലാകാൻ തുടങ്ങി. തുടക്കത്തിൽ, അത് ക്രാഷ് ചെയ്തില്ല, അത് രസകരമാണ്, കോഡ് അവിടെ ചേർത്തിട്ടില്ല, കാരണം ഇത് ഒരു അടിസ്ഥാന ബ്രോക്കറായിരുന്നു, പ്രായോഗികമായി ബിസിനസ്സ് പ്രവർത്തനങ്ങളൊന്നുമില്ല - ഇത് വ്യക്തിഗത സേവനങ്ങൾക്കിടയിൽ സന്ദേശങ്ങൾ അയച്ചു. 4 മാസത്തേക്ക് ഈ സേവനം മാറിയില്ല, പെട്ടെന്ന് അത് "സെഗ്മെന്റേഷൻ തകരാർ" പിശക് കൊണ്ട് തകരാറിലാകാൻ തുടങ്ങി.

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

- സുഹൃത്തുക്കളേ, ഒന്നര ആഴ്ച മുമ്പ് നിങ്ങൾക്ക് എന്താണ് സംഭവിച്ചത്?

പ്രതികരണമായി, അവർ UI എങ്ങനെ പുനർരൂപകൽപ്പന ചെയ്‌തു എന്നതിനെക്കുറിച്ചുള്ള രസകരമായ ഒരു കഥ ഞങ്ങൾ കേട്ടു. എച്ച്ടിടിപി ലൈബ്രറി മാറ്റിയതായി ആരും ഉടൻ പറയാനിടയില്ല. ആൻഡ്രോയിഡ് ക്ലയന്റുകൾക്ക്, ഇത് ബാത്ത്റൂമിൽ സോപ്പ് മാറ്റുന്നത് പോലെയാണ് - അവർ ഓർക്കുന്നില്ല. തൽഫലമായി, 40 മിനിറ്റ് സംഭാഷണത്തിന് ശേഷം, അവർ HTTP ലൈബ്രറി മാറ്റിയെന്നും അതിന്റെ സ്ഥിരസ്ഥിതി സമയവും മാറിയെന്നും ഞങ്ങൾ കണ്ടെത്തി. ഇത് എപിഐ സെർവറിലെ ട്രാഫിക് സ്വഭാവം മാറുന്നതിലേക്ക് നയിച്ചു, ഇത് ബ്രോക്കറിനുള്ളിൽ ഒരു ഓട്ടത്തിന് കാരണമായ ഒരു സാഹചര്യത്തിലേക്ക് നയിച്ചു, അത് തകരാൻ തുടങ്ങി.

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

ഡെലിവറി പ്രക്രിയയുടെ ഓരോ ഘട്ടത്തിലും ആർട്ടിഫാക്റ്റിന് എന്ത് സംഭവിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള എല്ലാ വിവരങ്ങളും ശേഖരിക്കുക - നിർമ്മാണത്തിലല്ല.

നിരീക്ഷണം CI-ലേക്ക് അപ്‌ലോഡ് ചെയ്യുക, ചില അടിസ്ഥാന കാര്യങ്ങൾ ഇതിനകം അവിടെ ദൃശ്യമാകും. പിന്നീട് നിങ്ങൾ അവ ടെസ്റ്റ്, പ്രെഡ്‌പ്രോഡ്, ലോഡ് ടെസ്റ്റിംഗ് എന്നിവയിൽ കാണും. എല്ലാ ഘട്ടങ്ങളിലും വിവരങ്ങൾ ശേഖരിക്കുക, അളവുകൾ, സ്ഥിതിവിവരക്കണക്കുകൾ മാത്രമല്ല, ലോഗുകളും: ആപ്ലിക്കേഷൻ എങ്ങനെയാണ് പുറത്തുവന്നത്, അപാകതകൾ - എല്ലാം ശേഖരിക്കുക.

അല്ലെങ്കിൽ അത് കണ്ടുപിടിക്കാൻ ബുദ്ധിമുട്ടായിരിക്കും. DevOps കൂടുതൽ സങ്കീർണ്ണമാണെന്ന് ഞാൻ ഇതിനകം പറഞ്ഞു. ഈ സങ്കീർണ്ണതയെ നേരിടാൻ, നിങ്ങൾക്ക് സാധാരണ വിശകലനം ആവശ്യമാണ്.

ആത്മനിയന്ത്രണത്തിനുള്ള ചോദ്യങ്ങൾ

നിങ്ങളുടെ നിരീക്ഷണവും ലോഗിംഗും നിങ്ങൾക്കുള്ള വികസന ഉപകരണമാണോ? കോഡ് എഴുതുമ്പോൾ, നിങ്ങളുൾപ്പെടെയുള്ള നിങ്ങളുടെ ഡെവലപ്പർമാർ അത് എങ്ങനെ നിരീക്ഷിക്കാമെന്ന് ചിന്തിക്കുന്നുണ്ടോ?

ഉപഭോക്താക്കളിൽ നിന്നുള്ള പ്രശ്നങ്ങളെക്കുറിച്ച് നിങ്ങൾ കേൾക്കുന്നുണ്ടോ? മോണിറ്ററിംഗിൽ നിന്നും ലോഗിംഗിൽ നിന്നും നിങ്ങൾ ക്ലയന്റിനെ നന്നായി മനസ്സിലാക്കുന്നുണ്ടോ? നിരീക്ഷണത്തിൽ നിന്നും ലോഗിംഗിൽ നിന്നും നിങ്ങൾക്ക് സിസ്റ്റത്തെ നന്നായി മനസ്സിലാക്കാനാകുമോ? സിസ്റ്റത്തിലെ ട്രെൻഡ് വളരുന്നതും 3 ആഴ്ചയ്ക്കുള്ളിൽ എല്ലാം മരിക്കുമെന്ന് നിങ്ങൾ മനസ്സിലാക്കുന്നതും കണ്ടതുകൊണ്ടാണോ നിങ്ങൾ സിസ്റ്റം മാറ്റുന്നത്?

ഈ മൂന്ന് ഘടകങ്ങൾ നിങ്ങൾക്ക് ലഭിച്ചുകഴിഞ്ഞാൽ, നിങ്ങളുടെ കമ്പനിയിൽ ഏത് തരത്തിലുള്ള ഇൻഫ്രാസ്ട്രക്ചർ പ്ലാറ്റ്‌ഫോമാണ് ഉള്ളതെന്ന് നിങ്ങൾക്ക് ചിന്തിക്കാനാകും.

ഇൻഫ്രാസ്ട്രക്ചർ പ്ലാറ്റ്ഫോം

ഓരോ കമ്പനിക്കും ഉള്ള വ്യത്യസ്‌ത ഉപകരണങ്ങളുടെ ഒരു കൂട്ടമാണ് ഇത് എന്നല്ല കാര്യം.

എല്ലാ ടീമുകളും ഈ ടൂളുകൾ ഉപയോഗിക്കുകയും അവ ഒരുമിച്ച് വികസിപ്പിക്കുകയും ചെയ്യുക എന്നതാണ് ഒരു ഇൻഫ്രാസ്ട്രക്ചർ പ്ലാറ്റ്‌ഫോമിന്റെ കാര്യം.

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

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

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

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

ഈ ഘട്ടത്തിൽ, ഇൻഫ്രാസ്ട്രക്ചർ പ്ലാറ്റ്ഫോം നിങ്ങളുടെ മത്സര നേട്ടമായി മാറുന്നു, കാരണം അതിൽ മത്സരാർത്ഥിയുടെ ഉപകരണത്തിൽ ഇല്ലാത്ത എന്തെങ്കിലും അന്തർനിർമ്മിതമുണ്ട്. നിങ്ങളുടെ ഐപി ആഴം കൂടുന്നതിനനുസരിച്ച്, ടൈം-ടു-മാർക്കറ്റിന്റെ കാര്യത്തിൽ നിങ്ങളുടെ മത്സരാധിഷ്ഠിത നേട്ടം വർദ്ധിക്കും. ഇവിടെ ദൃശ്യമാകുന്നു വെണ്ടർ ലോക്ക് പ്രശ്നം: നിങ്ങൾക്ക് മറ്റൊരാളുടെ പ്ലാറ്റ്ഫോം എടുക്കാം, എന്നാൽ മറ്റൊരാളുടെ അനുഭവം ഉപയോഗിച്ച്, അത് നിങ്ങൾക്ക് എത്രത്തോളം പ്രസക്തമാണെന്ന് നിങ്ങൾക്ക് മനസ്സിലാകില്ല. അതെ, എല്ലാ കമ്പനികൾക്കും ആമസോൺ പോലെ ഒരു പ്ലാറ്റ്ഫോം നിർമ്മിക്കാൻ കഴിയില്ല. കമ്പനിയുടെ അനുഭവം വിപണിയിലെ അതിന്റെ സ്ഥാനത്തിന് പ്രസക്തമായ ഒരു ബുദ്ധിമുട്ടുള്ള വരിയാണിത്, നിങ്ങൾക്ക് അവിടെ ഒരു വെണ്ടർ ലോക്ക് ഉപയോഗിക്കാൻ കഴിയില്ല. ഇതും ചിന്തിക്കേണ്ടത് പ്രധാനമാണ്.

പദ്ധതി

ഒരു DevOps കമ്പനിയിൽ എല്ലാ പ്രവർത്തനങ്ങളും പ്രക്രിയകളും സജ്ജീകരിക്കാൻ നിങ്ങളെ സഹായിക്കുന്ന ഒരു ഇൻഫ്രാസ്ട്രക്ചർ പ്ലാറ്റ്‌ഫോമിന്റെ അടിസ്ഥാന ഡയഗ്രം ആണിത്.

അതിൽ എന്താണ് അടങ്ങിയിരിക്കുന്നതെന്ന് നോക്കാം.

റിസോഴ്സ് ഓർക്കസ്ട്രേഷൻ സിസ്റ്റം, ഇത് ആപ്ലിക്കേഷനുകൾക്കും മറ്റ് സേവനങ്ങൾക്കും സിപിയു, മെമ്മറി, ഡിസ്ക് എന്നിവ നൽകുന്നു. ഇതിന് മുകളിൽ - താഴ്ന്ന നിലയിലുള്ള സേവനങ്ങൾ: നിരീക്ഷണം, ലോഗിംഗ്, CI/CD എഞ്ചിൻ, ആർട്ടിഫാക്റ്റ് സ്റ്റോറേജ്, സിസ്റ്റം കോഡായി അടിസ്ഥാന സൗകര്യങ്ങൾ.

ഉയർന്ന തലത്തിലുള്ള സേവനങ്ങൾ: ഒരു സേവനമായി ഡാറ്റാബേസ്, ഒരു സേവനമായി ക്യൂകൾ, ഒരു സേവനമായി ബാലൻസ് ലോഡ് ചെയ്യുക, ഒരു സേവനമായി ഇമേജ് വലുപ്പം മാറ്റുക, ഒരു സേവനമായി ബിഗ് ഡാറ്റ ഫാക്ടറി. ഇതിന് മുകളിൽ - നിങ്ങളുടെ ക്ലയന്റിലേക്ക് നിരന്തരം പരിഷ്കരിച്ച കോഡ് നൽകുന്ന പൈപ്പ്ലൈൻ.

ക്ലയന്റിനായി നിങ്ങളുടെ സോഫ്‌റ്റ്‌വെയർ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ നിങ്ങൾക്ക് ലഭിക്കും, അത് മാറ്റുക, ഈ കോഡ് വീണ്ടും നൽകുക, വിവരങ്ങൾ സ്വീകരിക്കുക - അങ്ങനെ നിങ്ങൾ ഇൻഫ്രാസ്ട്രക്ചർ പ്ലാറ്റ്‌ഫോമും നിങ്ങളുടെ സോഫ്‌റ്റ്‌വെയറും നിരന്തരം വികസിപ്പിക്കുന്നു.

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

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

പ്ലാറ്റ്ഫോം സൃഷ്ടിക്കൽ

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

സംസ്കാരത്തിൽ എല്ലാം വളരെ ലളിതമാണ് - ഇത് സഹകരണത്തിന്റെയും ആശയവിനിമയത്തിന്റെയും കാര്യമാണ്, അതായത്, പരസ്പരം ഒരു പൊതു മേഖലയിൽ പ്രവർത്തിക്കാനുള്ള ആഗ്രഹം, ഒരു ഉപകരണം ഒരുമിച്ച് ഉപയോഗിക്കാനുള്ള ആഗ്രഹം. ഇവിടെ റോക്കറ്റ് സയൻസ് ഇല്ല - എല്ലാം വളരെ ലളിതമാണ്, നിസ്സാരമാണ്. ഉദാഹരണത്തിന്, നാമെല്ലാവരും പ്രവേശന കവാടത്തിൽ താമസിക്കുകയും അത് വൃത്തിയായി സൂക്ഷിക്കുകയും ചെയ്യുന്നു - അത്തരമൊരു തലത്തിലുള്ള സംസ്കാരം.

നിങ്ങൾക്ക് എന്താണ് ഉള്ളത്?

വീണ്ടും, നിങ്ങൾക്ക് സ്വയം ചോദിക്കാൻ കഴിയുന്ന ചോദ്യങ്ങൾ.

ഇൻഫ്രാസ്ട്രക്ചർ പ്ലാറ്റ്ഫോം സമർപ്പിതമാണോ? അതിന്റെ വികസനത്തിന് ആരാണ് ഉത്തരവാദി? നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ പ്ലാറ്റ്‌ഫോമിന്റെ മത്സരപരമായ നേട്ടങ്ങൾ നിങ്ങൾ മനസ്സിലാക്കുന്നുണ്ടോ?

ഈ ചോദ്യങ്ങൾ നിങ്ങൾ സ്വയം നിരന്തരം ചോദിക്കേണ്ടതുണ്ട്. മൂന്നാം കക്ഷി സേവനങ്ങളിലേക്ക് എന്തെങ്കിലും കൈമാറാൻ കഴിയുമെങ്കിൽ, അത് കൈമാറണം; ഒരു മൂന്നാം കക്ഷി സേവനം നിങ്ങളുടെ ചലനത്തെ തടയാൻ തുടങ്ങിയാൽ, നിങ്ങൾ സ്വയം ഒരു സിസ്റ്റം നിർമ്മിക്കേണ്ടതുണ്ട്.

അതിനാൽ, DevOps...

... ഇതൊരു സങ്കീർണ്ണ സംവിധാനമാണ്, അതിൽ ഉണ്ടായിരിക്കണം:

• ഡിജിറ്റൽ ഉൽപ്പന്നം.
• ഈ ഡിജിറ്റൽ ഉൽപ്പന്നം വികസിപ്പിക്കുന്ന ബിസിനസ് മൊഡ്യൂളുകൾ.
• കോഡ് എഴുതുന്ന ഉൽപ്പന്ന ടീമുകൾ.
• തുടർച്ചയായ ഡെലിവറി രീതികൾ.
• ഒരു സേവനമായി പ്ലാറ്റ്ഫോമുകൾ.
• ഒരു സേവനമെന്ന നിലയിൽ അടിസ്ഥാന സൗകര്യങ്ങൾ.
• അടിസ്ഥാന സൗകര്യങ്ങൾ കോഡായി.
• DevOps-ൽ നിർമ്മിച്ച വിശ്വാസ്യത നിലനിർത്തുന്നതിനുള്ള പ്രത്യേക സമ്പ്രദായങ്ങൾ.
• എല്ലാം വിവരിക്കുന്ന ഒരു ഫീഡ്ബാക്ക് പ്രാക്ടീസ്.

നിങ്ങൾക്ക് ഈ ഡയഗ്രം ഉപയോഗിക്കാം, ഏതെങ്കിലും രൂപത്തിൽ നിങ്ങളുടെ കമ്പനിയിൽ ഇതിനകം ഉള്ളത് അതിൽ എടുത്തുകാണിക്കുന്നു: ഇത് വികസിപ്പിച്ചിട്ടുണ്ടോ അല്ലെങ്കിൽ ഇപ്പോഴും വികസിപ്പിക്കേണ്ടതുണ്ട്.

രണ്ടാഴ്ചയ്ക്കുള്ളിൽ അത് തീരും DevOpsConf 2019. RIT++ ന്റെ ഭാഗമായി. കോൺഫറൻസിലേക്ക് വരൂ, അവിടെ തുടർച്ചയായ ഡെലിവറി, കോഡായി അടിസ്ഥാന സൗകര്യങ്ങൾ, DevOps പരിവർത്തനം എന്നിവയെക്കുറിച്ചുള്ള നിരവധി രസകരമായ റിപ്പോർട്ടുകൾ നിങ്ങൾ കണ്ടെത്തും. നിങ്ങളുടെ ടിക്കറ്റുകൾ ബുക്ക് ചെയ്യുക, അവസാന വിലയുടെ അവസാന തീയതി മെയ് 20 ആണ്

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