DevOps തത്ത്വങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ള ഏഴ് രൂപാന്തര ആർക്കൈപ്പുകൾ

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

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

ജോൺ വില്ലിസ് - DevOps-ന്റെ പിതാക്കന്മാരിൽ ഒരാൾ. ജോണിന് നിരവധി കമ്പനികളിൽ പതിറ്റാണ്ടുകളുടെ പരിചയമുണ്ട്. അടുത്തിടെ, അവയിൽ ഓരോന്നിനും പ്രവർത്തിക്കുമ്പോൾ സംഭവിക്കുന്ന നിർദ്ദിഷ്ട പാറ്റേണുകൾ ജോൺ ശ്രദ്ധിക്കാൻ തുടങ്ങി. ഈ പുരാരൂപങ്ങൾ ഉപയോഗിച്ച്, DevOps പരിവർത്തനത്തിന്റെ യഥാർത്ഥ പാതയിലേക്ക് ജോൺ കമ്പനികളെ നയിക്കുന്നു. DevOops 2018 കോൺഫറൻസിൽ നിന്നുള്ള അദ്ദേഹത്തിന്റെ റിപ്പോർട്ടിന്റെ വിവർത്തനത്തിൽ ഈ പുരാരൂപങ്ങളെക്കുറിച്ച് കൂടുതൽ വായിക്കുക.

സ്പീക്കറെ കുറിച്ച്:

ഐടി മാനേജ്‌മെന്റിൽ 35 വർഷത്തിലേറെയായി, കാനോനിക്കലിൽ ഓപ്പൺക്ലൗഡിന്റെ മുൻഗാമിയുടെ സൃഷ്ടിയിൽ പങ്കെടുത്തു, 10 സ്റ്റാർട്ടപ്പുകളിൽ പങ്കെടുത്തു, അവയിൽ രണ്ടെണ്ണം ഡെല്ലിനും ഡോക്കറിനും വിറ്റു. നിലവിൽ SJ ടെക്നോളജീസിലെ DevOps, ഡിജിറ്റൽ പ്രാക്ടീസ് എന്നിവയുടെ വൈസ് പ്രസിഡന്റാണ്.

ജോണിന്റെ വീക്ഷണകോണിൽ നിന്നുള്ള കഥയാണ് അടുത്തത്.

എന്റെ പേര് ജോൺ വില്ലിസ്, എന്നെ കണ്ടെത്താൻ ഏറ്റവും എളുപ്പമുള്ള സ്ഥലം ട്വിറ്ററിലാണ്, @botchagalupe. എനിക്ക് Gmail-ലും GitHub-ലും ഇതേ അപരനാമമുണ്ട്. എ ഈ ലിങ്ക് വഴി എന്റെ റിപ്പോർട്ടുകളുടെയും അവതരണങ്ങളുടെയും വീഡിയോ റെക്കോർഡിംഗുകൾ നിങ്ങൾക്ക് കണ്ടെത്താനാകും.

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

എന്താണ് DevOps?

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

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

അവസാനം ഞാൻ താഴെ കൊടുത്തു DevOps-ന്റെ നിർവ്വചനം: മാനുഷിക മൂലധനത്തെ ഉയർന്ന പ്രവർത്തനക്ഷമതയുള്ള സംഘടനാ മൂലധനമാക്കി മാറ്റാൻ പ്രാപ്തമാക്കുന്ന സമ്പ്രദായങ്ങളുടെയും പാറ്റേണുകളുടെയും ഒരു കൂട്ടമാണിത്. കഴിഞ്ഞ 50-60 വർഷമായി ടൊയോട്ടയുടെ പ്രവർത്തന രീതി തന്നെ ഉദാഹരണം.

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

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

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

മോശം സംസ്കാരം പ്രഭാതഭക്ഷണത്തിന് നല്ല സമീപനങ്ങൾ കഴിക്കുന്നു

പ്രധാന ആശയം ഇതാണ്: ഓർഗനൈസേഷന്റെ സംസ്കാരം തന്നെ മോശമാണെങ്കിൽ, ലീൻ, എജൈൽ, സേഫ്, ഡെവോപ്സ് എന്നിവയൊന്നും സഹായിക്കില്ല. ഇത് സ്കൂബ ഗിയറില്ലാതെ ആഴത്തിൽ മുങ്ങുകയോ എക്സ്-റേ ഇല്ലാതെ പ്രവർത്തിക്കുകയോ ചെയ്യുന്നതുപോലെയാണ്. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഡ്രക്കറെയും ഡെമിംഗിനെയും വ്യാഖ്യാനിക്കാൻ: ഒരു മോശം സംഘടനാ സംസ്കാരം ഏത് നല്ല സംവിധാനത്തെയും ശ്വാസം മുട്ടിക്കാതെ വിഴുങ്ങും.

ഈ പ്രധാന പ്രശ്നം പരിഹരിക്കുന്നതിന്, നിങ്ങൾ ഇനിപ്പറയുന്ന ഘട്ടങ്ങൾ ചെയ്യേണ്ടതുണ്ട്:

1. എല്ലാ ജോലികളും ദൃശ്യമാക്കുക: നിങ്ങൾ എല്ലാ ജോലികളും ദൃശ്യമാക്കേണ്ടതുണ്ട്. ചില സ്ക്രീനിൽ അത് പ്രദർശിപ്പിക്കണം എന്ന അർത്ഥത്തിലല്ല, മറിച്ച് അത് നിരീക്ഷിക്കപ്പെടണം എന്ന അർത്ഥത്തിലാണ്.
2. ഏകീകൃത വർക്ക് മാനേജ്മെന്റ് സിസ്റ്റങ്ങൾ: മാനേജ്മെന്റ് സംവിധാനങ്ങൾ ഏകീകരിക്കേണ്ടതുണ്ട്. "ആദിവാസി" വിജ്ഞാനത്തിന്റെയും സ്ഥാപനപരമായ അറിവിന്റെയും പ്രശ്നത്തിൽ, 9 കേസുകളിൽ 10 കേസുകളിലും തടസ്സം നിൽക്കുന്നത് ആളുകളാണ്. പുസ്തകത്തിൽ "ഫീനിക്സ് പദ്ധതി" പ്രോജക്റ്റ് ഷെഡ്യൂൾ ചെയ്യാൻ മൂന്ന് വർഷം പിന്നിടാൻ കാരണമായ ബ്രെന്റ് എന്ന ഒരൊറ്റ വ്യക്തിയുടെ പ്രശ്നമായിരുന്നു. ഞാൻ എല്ലായിടത്തും ഈ "ബ്രന്റുകളിൽ" ഓടുന്നു. ഈ തടസ്സങ്ങൾ പരിഹരിക്കാൻ, ഞങ്ങളുടെ ലിസ്റ്റിലെ അടുത്ത രണ്ട് ഇനങ്ങൾ ഞാൻ ഉപയോഗിക്കുന്നു.
3. നിയന്ത്രണ രീതിശാസ്ത്രത്തിന്റെ സിദ്ധാന്തം: നിയന്ത്രണങ്ങളുടെ സിദ്ധാന്തം.
4. സഹകരണ ഹാക്കുകൾ: സഹകരണ ഹാക്കുകൾ.
5. ടൊയോട്ട കാറ്റ (കാറ്റാ കോച്ചിംഗ്): ടൊയോട്ട കാറ്റയെക്കുറിച്ച് ഞാൻ അധികം സംസാരിക്കില്ല. താൽപ്പര്യമുണ്ടെങ്കിൽ, എന്റെ ഗിത്തബിൽ അവതരണങ്ങൾ ഉണ്ട് ഈ വിഷയങ്ങളിൽ മിക്കവാറും എല്ലാ വിഷയങ്ങളിലും.
6. മാർക്കറ്റ് ഓറിയന്റഡ് ഓർഗനൈസേഷൻ: വിപണി അധിഷ്ഠിത സംഘടന.
7. ഷിഫ്റ്റ്-ലെഫ്റ്റ് ഓഡിറ്റർമാർ: സൈക്കിളിന്റെ പ്രാരംഭ ഘട്ടത്തിലെ ഓഡിറ്റ്.

ഞാൻ വളരെ ലളിതമായി ഒരു ഓർഗനൈസേഷനുമായി പ്രവർത്തിക്കാൻ തുടങ്ങുന്നു: ഞാൻ കമ്പനിയിൽ പോയി ജീവനക്കാരുമായി സംസാരിക്കുന്നു. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഉയർന്ന സാങ്കേതികവിദ്യയില്ല. നിങ്ങൾക്ക് വേണ്ടത് എഴുതാൻ എന്തെങ്കിലും മാത്രം. ഞാൻ ഒരു മുറിയിൽ നിരവധി ടീമുകളെ ശേഖരിക്കുകയും എന്റെ 7 ആർക്കൈപ്പുകളുടെ വീക്ഷണകോണിൽ നിന്ന് അവർ എന്നോട് പറയുന്ന കാര്യങ്ങൾ വിശകലനം ചെയ്യുകയും ചെയ്യുന്നു. എന്നിട്ട് ഞാൻ അവർക്ക് തന്നെ ഒരു മാർക്കർ നൽകി, അവർ ഇതുവരെ ഉറക്കെ പറഞ്ഞതെല്ലാം ബോർഡിൽ എഴുതാൻ ആവശ്യപ്പെടുന്നു. സാധാരണയായി ഇത്തരത്തിലുള്ള മീറ്റിംഗുകളിൽ എല്ലാം എഴുതുന്ന ഒരു വ്യക്തിയുണ്ട്, കൂടാതെ ചർച്ചയുടെ 10% എഴുതാൻ അദ്ദേഹത്തിന് കഴിയും. എന്റെ രീതി ഉപയോഗിച്ച്, ഈ കണക്ക് ഏകദേശം 40% ആയി ഉയർത്താം.

(ഈ ചിത്രം പ്രത്യേകം കാണാവുന്നതാണ് ലിങ്ക് കാണുക)

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

ഉയർന്ന തലത്തിലുള്ള നിയന്ത്രണവും കഴിവും ഉള്ളതാണ് അൽപ്പം മികച്ച ഓപ്ഷൻ. അത്തരമൊരു കമ്പനി ലാഭകരമാണെങ്കിൽ, ഒരുപക്ഷേ അതിന് DevOps ആവശ്യമില്ല. ഉയർന്ന തലത്തിലുള്ള നിയന്ത്രണവും കുറഞ്ഞ കഴിവും സഹകരണവും ഉള്ള ഒരു കമ്പനിയുമായി പ്രവർത്തിക്കുന്നത് ഏറ്റവും രസകരമാണ്, എന്നാൽ അതേ സമയം ഉയർന്ന തലത്തിലുള്ള സംസ്കാരം (കൃഷി). ഇതിനർത്ഥം കമ്പനിയിൽ ജോലി ചെയ്യാൻ ഇഷ്ടപ്പെടുന്ന ധാരാളം ആളുകൾ ഉണ്ടെന്നും തൊഴിൽ വിറ്റുവരവ് കുറവാണ്.

(ഈ ചിത്രം പ്രത്യേകം കാണാവുന്നതാണ് ലിങ്ക് കാണുക)

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

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

(ഈ ചിത്രം പ്രത്യേകം കാണാവുന്നതാണ് ലിങ്ക് കാണുക)

ഈ സമീപനത്തിന്റെ ഒരു ഉദാഹരണം ഇപ്പോൾ മുകളിൽ ചിത്രീകരിച്ചിരിക്കുന്നു. ഈ വർഷത്തിന്റെ തുടക്കത്തിൽ ഞാൻ ഒരു ബാങ്കിൽ ജോലി ചെയ്തു. അവിടെയുള്ള സെക്യൂരിറ്റി ആളുകൾക്ക് അവർ ഡിസൈൻ ചെയ്യാനും ആവശ്യാനുസരണം റിവ്യൂ ചെയ്യാനും വരേണ്ടതില്ലെന്ന് ബോധ്യപ്പെട്ടു.

(ഈ ചിത്രം പ്രത്യേകം കാണാവുന്നതാണ് ലിങ്ക് കാണുക)

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

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

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

(ഈ ചിത്രം പ്രത്യേകം കാണാവുന്നതാണ് ലിങ്ക് കാണുക)

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

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

അതിനാൽ, ഞാൻ തൊഴിലാളികളോട് ചോദ്യങ്ങൾ ചോദിക്കുന്നു, അവർ മൂന്ന് നിറങ്ങളുടെ (കറുപ്പ്, ചുവപ്പ്, നീല) മാർക്കറുകൾ ഉപയോഗിച്ച് ഉത്തരങ്ങൾ എഴുതുന്നു. ആർക്കൈറ്റിപ്പുകൾക്കായി ഞാൻ അവരുടെ ഉത്തരങ്ങൾ വിശകലനം ചെയ്യുന്നു. ഇപ്പോൾ നമുക്ക് എല്ലാ ആർക്കിറ്റൈപ്പുകളും ക്രമത്തിൽ ചർച്ച ചെയ്യാം.

1. എല്ലാ ജോലികളും ദൃശ്യമാക്കുക: ജോലി ദൃശ്യമാക്കുക

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

• വളരെയധികം ജോലി പ്രക്രിയയിലാണ് (WIP)
• അജ്ഞാത ആശ്രിതത്വം
• ആസൂത്രിതമല്ലാത്ത ജോലി
• വൈരുദ്ധ്യമുള്ള മുൻഗണനകൾ
• അവഗണിക്കപ്പെട്ട ജോലി

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

മൂന്ന് വർഷം വൈകിപ്പോയ ഒരു പ്രോജക്റ്റിനെക്കുറിച്ചുള്ള അതിശയകരമായ കഥയാണ് ഫീനിക്സ് പ്രോജക്റ്റ്. ഇക്കാരണത്താൽ, ഒരു കഥാപാത്രം പിരിച്ചുവിടലിനെ അഭിമുഖീകരിക്കുന്നു, ഒരുതരം സോക്രട്ടീസിന്റെ വേഷത്തിൽ അവതരിപ്പിക്കപ്പെടുന്ന മറ്റൊരു കഥാപാത്രത്തെ അദ്ദേഹം കണ്ടുമുട്ടുന്നു. എന്താണ് തെറ്റ് സംഭവിച്ചതെന്ന് മനസിലാക്കാൻ അവൻ സഹായിക്കുന്നു. കമ്പനിക്ക് ഒരു സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർ ഉണ്ടെന്ന് മാറുന്നു, അദ്ദേഹത്തിന്റെ പേര് ബ്രെന്റ്, എല്ലാ ജോലികളും എങ്ങനെയെങ്കിലും അവനിലൂടെ നടക്കുന്നു. ഒരു മീറ്റിംഗിൽ, കീഴുദ്യോഗസ്ഥരിൽ ഒരാളോട് ചോദിക്കുന്നു: ഓരോ അര മണിക്കൂർ ജോലിയും ഒരാഴ്ച എടുക്കുന്നത് എന്തുകൊണ്ട്? ക്യൂയിംഗ് തിയറിയുടെയും ലിറ്റിൽസ് നിയമത്തിന്റെയും വളരെ ലളിതമായ അവതരണമാണ് ഉത്തരം, ഈ അവതരണത്തിൽ 90% ഒക്യുപൻസിയിൽ, ഓരോ മണിക്കൂറും 9 മണിക്കൂർ ജോലി എടുക്കുന്നു. ഓരോ ടാസ്‌ക്കും മറ്റ് ഏഴ് പേർക്ക് അയയ്‌ക്കേണ്ടതുണ്ട്, അങ്ങനെ ആ മണിക്കൂർ 63 മണിക്കൂർ, 7 തവണ 9 ആയി മാറുന്നു. ലിറ്റിൽസ് ലോ അല്ലെങ്കിൽ ഏതെങ്കിലും സങ്കീർണ്ണമായ ക്യൂയിംഗ് സിദ്ധാന്തം ഉപയോഗിക്കുന്നതിന്, നിങ്ങൾക്ക് കുറഞ്ഞത് ഡാറ്റയെങ്കിലും ഉണ്ടായിരിക്കണം എന്നതാണ്.

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

ജോലി ദൃശ്യമാകുമ്പോൾ, ഡാറ്റ ഭംഗിയായി തരംതിരിക്കാം (ഫോട്ടോയിൽ ഡൊമിനിക് ചെയ്യുന്നത് അതാണ്), അഞ്ച് തവണ ചോർച്ചയുടെ അമൂർത്തീകരണം പ്രയോഗിക്കാനും ഓട്ടോമേഷൻ പ്രയോഗിക്കാനും കഴിയും.

2. വർക്ക് മാനേജ്മെന്റ് സിസ്റ്റങ്ങൾ ഏകീകരിക്കുക: ടാസ്ക് മാനേജ്മെന്റ്

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

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

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

അടിസ്ഥാന സൗകര്യങ്ങളും പ്രവർത്തനങ്ങളും ഉൾപ്പെടെ എല്ലാ വകുപ്പുകൾക്കും ഇത് ബാധകമാണ്. ഈ സാഹചര്യത്തിൽ, കാര്യങ്ങളുടെ അവസ്ഥയെക്കുറിച്ച് വിശ്വസനീയമായ ചില ആശയങ്ങളെങ്കിലും രൂപപ്പെടുത്താൻ കഴിയും. ഈ പ്രക്രിയ സ്ഥാപിച്ചുകഴിഞ്ഞാൽ, ഓരോ ആപ്ലിക്കേഷന്റെയും ഉത്തരവാദിത്തം ആരാണെന്ന് പെട്ടെന്ന് തിരിച്ചറിയുന്നത് എളുപ്പമാകും. കാരണം ഇപ്പോൾ നമുക്ക് ലഭിക്കുന്നത് 50% അല്ല, 98% പുതിയ സേവനങ്ങളാണ്. ഈ പ്രധാന പ്രക്രിയ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, സിസ്റ്റത്തിലുടനീളം കൃത്യത മെച്ചപ്പെടുന്നു.

സേവന പൈപ്പ്ലൈൻ

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

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

3. നിയന്ത്രണങ്ങളുടെ സിദ്ധാന്തം: നിയന്ത്രണങ്ങളുടെ സിദ്ധാന്തം

നമുക്ക് മൂന്നാമത്തെ ആർക്കൈപ്പിലേക്ക് പോകാം: സ്ഥാപന/"ഗോത്ര" അറിവ്. ചട്ടം പോലെ, ഏതൊരു ഓർഗനൈസേഷനിലും എല്ലാം അറിയുകയും എല്ലാം കൈകാര്യം ചെയ്യുകയും ചെയ്യുന്ന നിരവധി ആളുകൾ ഉണ്ട്. ഇവരാണ് സംഘടനയിൽ ഏറ്റവും കൂടുതൽ കാലം പ്രവർത്തിച്ചവരും എല്ലാ പരിഹാര മാർഗങ്ങളും അറിയുന്നവരും.

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

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

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

4. സഹകരണ ഹാക്കുകൾ: സഹകരണ ഹാക്കുകൾ

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

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

5. കോച്ചിംഗ് കാറ്റ

തുടക്കത്തിൽ തന്നെ ഞാൻ മുന്നറിയിപ്പ് നൽകിയതുപോലെ, ഇന്ന് ഞാൻ ഇതിനെക്കുറിച്ച് സംസാരിക്കില്ല. നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് നോക്കാം എന്റെ ചില അവതരണങ്ങൾ.

മൈക്ക് റോതറിൽ നിന്ന് ഈ വിഷയത്തിൽ ഒരു നല്ല സംഭാഷണവും ഉണ്ട്:

6. മാർക്കറ്റ് ഓറിയന്റഡ്: മാർക്കറ്റ് ഓറിയന്റഡ് ഓർഗനൈസേഷൻ

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

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

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

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

7. ഷിഫ്റ്റ്-ലെഫ്റ്റ് ഓഡിറ്റർമാർ: സൈക്കിളിന്റെ തുടക്കത്തിൽ തന്നെ ഓഡിറ്റ് ചെയ്യുക. പ്രദർശിപ്പിച്ചിരിക്കുന്ന സുരക്ഷാ നിയമങ്ങൾ പാലിക്കൽ

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

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

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

പറയുന്നു റിപ്പോർട്ട്, 2018-ൽ Sonatype സൃഷ്ടിച്ചത്, 2017-ൽ 87 ബില്യൺ OSS ഡൗൺലോഡ് അഭ്യർത്ഥനകൾ ഉണ്ടായി.

കേടുപാടുകൾ മൂലമുണ്ടാകുന്ന നഷ്ടം വളരെ വലുതാണ്. മാത്രമല്ല, നിങ്ങൾ ഇപ്പോൾ മുകളിൽ കാണുന്ന കണക്കുകളിൽ അവസര ചെലവുകൾ ഉൾപ്പെടുന്നില്ല. ചുരുക്കത്തിൽ എന്താണ് DevSecOps? ഈ പേര് എത്രത്തോളം വിജയകരമാണെന്ന് സംസാരിക്കാൻ എനിക്ക് താൽപ്പര്യമില്ലെന്ന് ഉടൻ തന്നെ പറയട്ടെ. DevOps വളരെ വിജയിച്ചതിനാൽ, ആ പൈപ്പ്ലൈനിൽ സുരക്ഷ ചേർക്കാൻ ഞങ്ങൾ ശ്രമിക്കണം എന്നതാണ് കാര്യം.

ഈ ശ്രേണിയുടെ ഒരു ഉദാഹരണം:


എനിക്ക് അവയെല്ലാം ഇഷ്‌ടമായെങ്കിലും, നിർദ്ദിഷ്ട ഉൽപ്പന്നങ്ങൾക്കുള്ള ശുപാർശയല്ല ഇത്. തുടക്കത്തിൽ വ്യവസായത്തിലെ ഓർഗനൈസേഷണൽ മാതൃകയെ അടിസ്ഥാനമാക്കിയിരുന്ന DevOps, ഒരു ഉൽപ്പന്നത്തിന്റെ എല്ലാ ഘട്ടങ്ങളും ഓട്ടോമേറ്റ് ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്നു എന്ന് കാണിക്കാൻ ഞാൻ അവരെ ഒരു ഉദാഹരണമായി ഉദ്ധരിച്ചു.

സുരക്ഷയുടെ കാര്യത്തിൽ ഞങ്ങൾക്ക് ഇതേ സമീപനം സ്വീകരിക്കാൻ കഴിയാത്തതിന് ഒരു കാരണവുമില്ല.

ഫലം

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

ഉപയോഗപ്രദമായ ലിങ്കുകൾ

DevOops കോൺഫറൻസിൽ നിന്ന് നിങ്ങൾക്ക് ഉപയോഗപ്രദമെന്ന് തോന്നിയേക്കാവുന്ന കുറച്ച് സംഭാഷണങ്ങൾ ഇതാ:

• സെർജി ബെർഡ്‌നിക്കോവ്, ആർട്ടിയോം കാലിച്ച്‌കിൻ - വിജയഗാഥ, അല്ലെങ്കിൽ “Dev+DevOps+Ops” (видео, റിപ്പോർട്ടിന്റെ ട്രാൻസ്ക്രിപ്റ്റ്)
• ബറൂച്ച് സഡോഗുർസ്‌കി, ലിയോനിഡ് ഇഗോൾനിക് - DevOps ഓൺ എ സ്കെയിൽ: മൂന്ന് പ്രവൃത്തികളിലെ ഒരു ഗ്രീക്ക് ദുരന്തം (видео, റിപ്പോർട്ടിന്റെ ട്രാൻസ്ക്രിപ്റ്റ്)
• അലക്സാണ്ടർ ടിറ്റോവ്, കിറിൽ ടോൾകച്ചേവ് - DevOps, എഞ്ചിനീയർമാർ, സമൂഹം
• തിമോത്തി ലിസ്റ്റർ - കഥാപാത്രങ്ങൾ, സമൂഹം, സംസ്കാരം: സമൃദ്ധിയുടെ പ്രധാന ഘടകങ്ങൾ

നോക്കുക പ്രോഗ്രാം DevOops 2020 മോസ്കോ - രസകരമായ ഒരുപാട് കാര്യങ്ങളും അവിടെയുണ്ട്.

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