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

ഈ അർത്ഥത്തിൽ, അദ്ദേഹം പങ്കുവെച്ച ലിയോൺ ഫയറിൻ്റെ അനുഭവം DevOpsConf, കൃത്യമായി അദ്വിതീയമല്ല, പക്ഷേ അദ്ദേഹത്തിൻ്റെ അനുഭവവും 20 വർഷത്തിനിടയിൽ അദ്ദേഹം പരീക്ഷിക്കാൻ കഴിഞ്ഞ വ്യത്യസ്ത റോളുകളുടെ എണ്ണവും കൊണ്ട് ഗുണിച്ചാൽ അത് വളരെ ഉപയോഗപ്രദമാണ്. 90 ദിവസത്തെ സംഭവങ്ങളുടെ കാലഗണനയും മറ്റൊരാൾക്ക് സംഭവിക്കുമ്പോൾ ചിരിക്കാൻ രസകരവും എന്നാൽ നേരിട്ട് അഭിമുഖീകരിക്കാൻ അത്ര രസകരമല്ലാത്തതുമായ ഒരുപാട് കഥകൾ കട്ടിന് താഴെയുണ്ട്.

ലിയോൺ റഷ്യൻ ഭാഷയിൽ വളരെ വർണ്ണാഭമായി സംസാരിക്കുന്നു, അതിനാൽ നിങ്ങൾക്ക് 35-40 മിനിറ്റ് ഉണ്ടെങ്കിൽ, വീഡിയോ കാണാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു. താഴെ സമയം ലാഭിക്കുന്നതിനുള്ള വാചക പതിപ്പ്.

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

ഒരു മാസം മുമ്പ്

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

ജനനം മുതൽ മൂന്ന് വയസ്സ് വരെ പ്രായമുള്ള വളരെ ചെറിയ കുട്ടികൾക്കുള്ള പാഠ്യപദ്ധതിയിൽ അദ്ധ്യാപന തന്ത്രങ്ങൾ ഒരു മാർക്കറ്റ് ലീഡറാണ്. പരമ്പരാഗത "പേപ്പർ" കമ്പനിക്ക് ഇതിനകം 40 വയസ്സ് പ്രായമുണ്ട്, കൂടാതെ പ്ലാറ്റ്‌ഫോമിൻ്റെ ഡിജിറ്റൽ SaaS പതിപ്പിന് 10 വർഷം പഴക്കമുണ്ട്, താരതമ്യേന അടുത്തിടെ, ഡിജിറ്റൽ സാങ്കേതികവിദ്യയെ കമ്പനി മാനദണ്ഡങ്ങളുമായി പൊരുത്തപ്പെടുത്തുന്ന പ്രക്രിയ ആരംഭിച്ചു. 2017-ൽ സമാരംഭിച്ച "പുതിയ" പതിപ്പ് ഏതാണ്ട് പഴയത് പോലെയായിരുന്നു, അത് മോശമായി പ്രവർത്തിച്ചു.

ഏറ്റവും രസകരമായ കാര്യം, ഈ കമ്പനിയുടെ ട്രാഫിക് വളരെ പ്രവചനാതീതമാണ് - ദിവസം തോറും, വർഷം തോറും, എത്ര ആളുകൾ വരുമെന്നും എപ്പോൾ വരുമെന്നും നിങ്ങൾക്ക് വളരെ വ്യക്തമായി പ്രവചിക്കാൻ കഴിയും. ഉദാഹരണത്തിന്, ഉച്ചയ്ക്ക് 13 നും 15 നും ഇടയിൽ കിൻ്റർഗാർട്ടനുകളിലെ എല്ലാ കുട്ടികളും ഉറങ്ങാൻ പോകുന്നു, അധ്യാപകർ വിവരങ്ങൾ നൽകാൻ തുടങ്ങുന്നു. വാരാന്ത്യങ്ങൾ ഒഴികെ എല്ലാ ദിവസവും ഇത് സംഭവിക്കുന്നു, കാരണം വാരാന്ത്യങ്ങളിൽ ആരും പ്രവർത്തിക്കില്ല.

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

2 വർഷം മാത്രം പഴക്കമുള്ള പ്ലാറ്റ്‌ഫോമിന് ഒരു പ്രത്യേക സ്റ്റാക്ക് ഉണ്ടായിരുന്നു: 2008 മുതൽ ColdFusion & SQL സെർവർ. കോൾഡ്ഫ്യൂഷൻ, നിങ്ങൾക്കറിയില്ലെങ്കിൽ, മിക്കവാറും നിങ്ങൾക്കറിയില്ലെങ്കിൽ, 90-കളുടെ മധ്യത്തിൽ പുറത്തുവന്ന ഒരു എൻ്റർപ്രൈസ് PHP ആണ്, അതിനുശേഷം ഞാൻ അതിനെക്കുറിച്ച് കേട്ടിട്ടുപോലുമില്ല. കൂടാതെ ഉണ്ടായിരുന്നു: റൂബി, MySQL, PostgreSQL, Java, Go, Python. എന്നാൽ പ്രധാന മോണോലിത്ത് കോൾഡ്ഫ്യൂഷനിലും SQL സെർവറിലും പ്രവർത്തിച്ചു.

പ്രശ്നങ്ങൾ

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

പരമ്പരാഗതമായി, അവരുടെ ടെക്കികൾ മൂലയിൽ ഇരുന്ന് എന്തെങ്കിലും ജോലികൾ ചെയ്തു. എന്നാൽ കൂടുതൽ കൂടുതൽ ബിസിനസ്സ് ഡിജിറ്റൽ പതിപ്പിലൂടെ പോകാൻ തുടങ്ങി. അതിനാൽ, ഞാൻ ജോലി ചെയ്യാൻ തുടങ്ങുന്നതിന് മുമ്പുള്ള അവസാന വർഷത്തിൽ, കമ്പനിയിൽ പുതിയവ പ്രത്യക്ഷപ്പെട്ടു: ഡയറക്ടർ ബോർഡ്, CTO, CPO, QA ഡയറക്ടർ. അതായത്, കമ്പനി സാങ്കേതിക മേഖലയിൽ നിക്ഷേപം ആരംഭിച്ചു.

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

രണ്ട് ദിവസം മുമ്പ്

ഒരു പുതിയ ജോലി ആരംഭിക്കുന്നതിന് രണ്ട് ദിവസം മുമ്പ്, ഞാൻ ഓഫീസിലെത്തി, അവസാന പേപ്പർ വർക്ക് പൂരിപ്പിച്ച്, ടീമിനെ കണ്ടു, ആ സമയത്ത് ടീം ഒരു പ്രശ്നവുമായി മല്ലിടുകയാണെന്ന് കണ്ടെത്തി. ശരാശരി പേജ് ലോഡിംഗ് സമയം 4 സെക്കൻഡിലേക്ക് ഉയർന്നു, അതായത് 2 മടങ്ങ്.

ഗ്രാഫ് അനുസരിച്ച്, എന്തെങ്കിലും വ്യക്തമായി സംഭവിച്ചു, അത് എന്താണെന്ന് വ്യക്തമല്ല. ഡാറ്റാ സെൻ്ററിലെ നെറ്റ്‌വർക്ക് ലേറ്റൻസിയാണ് പ്രശ്‌നം എന്ന് മനസ്സിലായി: ഡാറ്റാ സെൻ്ററിലെ 5 എംഎസ് ലേറ്റൻസി ഉപയോക്താക്കൾക്ക് 2 സെ ആയി മാറി. എന്തുകൊണ്ടാണ് ഇത് സംഭവിച്ചതെന്ന് എനിക്കറിയില്ല, പക്ഷേ ഏത് സാഹചര്യത്തിലും പ്രശ്നം ഡാറ്റാ സെൻ്ററിലാണെന്ന് മനസ്സിലായി.

ആദ്യ ദിവസം

രണ്ട് ദിവസം കടന്നുപോയി, എൻ്റെ ജോലിയുടെ ആദ്യ ദിവസം പ്രശ്നം നീങ്ങിയിട്ടില്ലെന്ന് ഞാൻ കണ്ടെത്തി.

രണ്ട് ദിവസത്തേക്ക്, ഉപയോക്താക്കളുടെ പേജുകൾ ശരാശരി 4 സെക്കൻഡിൽ ലോഡ് ചെയ്തു. എന്താണ് പ്രശ്നം എന്ന് അവർ കണ്ടെത്തിയോ എന്ന് ഞാൻ ചോദിക്കുന്നു.

- അതെ, ഞങ്ങൾ ഒരു ടിക്കറ്റ് തുറന്നു.
- ഒപ്പം?
- ശരി, അവർ ഇതുവരെ ഞങ്ങൾക്ക് ഉത്തരം നൽകിയിട്ടില്ല.

അപ്പോഴാണ് എനിക്ക് മനസ്സിലായത്, എന്നോട് മുമ്പ് പറഞ്ഞതെല്ലാം എനിക്ക് യുദ്ധം ചെയ്യേണ്ട മഞ്ഞുമലയുടെ ഒരു ചെറിയ അറ്റം മാത്രമാണെന്ന്.

ഇതിന് നന്നായി യോജിക്കുന്ന ഒരു നല്ല ഉദ്ധരണിയുണ്ട്:

"ചിലപ്പോൾ സാങ്കേതികവിദ്യ മാറ്റാൻ നിങ്ങൾ സ്ഥാപനം മാറ്റേണ്ടതുണ്ട്."

എന്നാൽ വർഷത്തിലെ ഏറ്റവും തിരക്കേറിയ സമയത്ത് ഞാൻ ജോലി ആരംഭിച്ചതിനാൽ, പ്രശ്നം പരിഹരിക്കുന്നതിനുള്ള രണ്ട് ഓപ്ഷനുകളും എനിക്ക് നോക്കേണ്ടി വന്നു: വേഗത്തിലും ദീർഘകാലമായും. ഇപ്പോൾ നിർണായകമായതിൽ നിന്ന് ആരംഭിക്കുക.

ദിവസം മൂന്ന്

അതിനാൽ, ലോഡിംഗ് 4 സെക്കൻഡ് നീണ്ടുനിൽക്കും, 13 മുതൽ 15 വരെ ഏറ്റവും വലിയ കൊടുമുടികൾ.

ഈ കാലയളവിൽ മൂന്നാം ദിവസം, ഡൗൺലോഡ് വേഗത ഇതുപോലെ കാണപ്പെട്ടു:

എൻ്റെ കാഴ്ചപ്പാടിൽ, ഒന്നും പ്രവർത്തിക്കുന്നില്ല. എല്ലാവരുടെയും കാഴ്ചപ്പാടിൽ, അത് പതിവിലും അൽപ്പം പതുക്കെയാണ് ഓടുന്നത്. എന്നാൽ അത് അങ്ങനെ സംഭവിക്കുന്നില്ല-ഇതൊരു ഗുരുതരമായ പ്രശ്നമാണ്.

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

എന്നാൽ നിങ്ങൾക്ക് ശരിയായ ഉത്തരം ലഭിക്കുന്നതിന് മുമ്പ്, നിങ്ങൾ ശരിയായ ചോദ്യം ചോദിക്കേണ്ടതുണ്ടെന്ന് നാം മറക്കരുത്. എൻ്റെ അടുത്ത ചോദ്യം ഇതായിരുന്നു: നമുക്ക് എത്ര ഫ്രണ്ട് എൻഡ് സെർവറുകൾ ഉണ്ട്? ഉത്തരം "എന്നെ അൽപ്പം അമ്പരപ്പിച്ചു" - ഞങ്ങൾക്ക് 17 ഫ്രണ്ട്എൻഡ് സെർവറുകൾ ഉണ്ടായിരുന്നു!

- എനിക്ക് ചോദിക്കാൻ ലജ്ജ തോന്നുന്നു, പക്ഷേ 150-നെ 17 കൊണ്ട് ഹരിച്ചാൽ ഏകദേശം 8 കിട്ടുമോ? ഓരോ സെർവറും സെക്കൻഡിൽ 8 അഭ്യർത്ഥനകൾ അനുവദിക്കുന്നുവെന്നാണോ നിങ്ങൾ പറയുന്നത്, നാളെ സെക്കൻഡിൽ 160 അഭ്യർത്ഥനകൾ ഉണ്ടെങ്കിൽ, ഞങ്ങൾക്ക് 2 സെർവറുകൾ കൂടി ആവശ്യമുണ്ടോ?

തീർച്ചയായും, ഞങ്ങൾക്ക് അധിക സെർവറുകൾ ആവശ്യമില്ല. പരിഹാരം കോഡിലും ഉപരിതലത്തിലും ഉണ്ടായിരുന്നു:

var currentClass = classes.getCurrentClass();
return currentClass;

ഒരു ചടങ്ങ് ഉണ്ടായിരുന്നു getCurrentClass(), കാരണം സൈറ്റിലെ എല്ലാം ഒരു ക്ലാസിൻ്റെ പശ്ചാത്തലത്തിൽ പ്രവർത്തിക്കുന്നു - അത് ശരിയാണ്. ഇതിനായി ഓരോ പേജിലും ഒരു ഫംഗ്‌ഷൻ ഉണ്ടായിരുന്നു 200+ അഭ്യർത്ഥനകൾ.

ഈ വഴിക്കുള്ള പരിഹാരം വളരെ ലളിതമായിരുന്നു, നിങ്ങൾക്ക് ഒന്നും തിരുത്തിയെഴുതേണ്ടതില്ല: അതേ വിവരങ്ങൾ വീണ്ടും ചോദിക്കരുത്.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

ഞാൻ വളരെ സന്തോഷവാനായിരുന്നു, കാരണം വെറും മൂന്നാം ദിവസം ഞാൻ പ്രധാന പ്രശ്നം കണ്ടെത്തി എന്ന് ഞാൻ തീരുമാനിച്ചു. ഞാൻ നിഷ്കളങ്കനായിരുന്നു, ഇത് പല പ്രശ്നങ്ങളിൽ ഒന്ന് മാത്രമായിരുന്നു.

എന്നാൽ ഈ ആദ്യ പ്രശ്നം പരിഹരിക്കുന്നത് ഗ്രാഫ് വളരെ താഴ്ന്നു.

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

ദിവസം പത്ത്

ആദ്യ ആഴ്ച ഞാൻ ഇപ്പോൾ പരിഹരിക്കേണ്ട പ്രശ്നങ്ങൾ കൈകാര്യം ചെയ്തു. രണ്ടാമത്തെ ആഴ്‌ചയിൽ എവിടെയോ, ടീമുമായി ആശയവിനിമയം നടത്താനും എന്താണ് സംഭവിക്കുന്നതെന്നും മുഴുവൻ പ്രക്രിയയും എങ്ങനെ നടക്കുന്നുവെന്നും കാണാൻ ഞാൻ ആദ്യമായി സ്റ്റാൻഡ്-അപ്പിലെത്തി.

രസകരമായ എന്തോ ഒന്ന് വീണ്ടും കണ്ടെത്തി. ടീം ഉൾപ്പെട്ടിരുന്നത്: 18 ഡെവലപ്പർമാർ; 8 ടെസ്റ്ററുകൾ; 3 മാനേജർമാർ; 2 ആർക്കിടെക്റ്റുകൾ. അവരെല്ലാം പൊതുവായ ആചാരങ്ങളിൽ പങ്കെടുത്തു, അതായത്, എല്ലാ ദിവസവും രാവിലെ 30-ലധികം ആളുകൾ സ്റ്റാൻഡ്-അപ്പിൽ വന്ന് അവർ എന്താണ് ചെയ്തതെന്ന് പറഞ്ഞു. യോഗം അഞ്ചോ പതിനഞ്ചോ മിനിറ്റ് എടുത്തില്ല എന്ന് വ്യക്തം. ഓരോരുത്തരും വ്യത്യസ്ത സംവിധാനങ്ങളിൽ പ്രവർത്തിക്കുന്നതിനാൽ ആരും ആരെയും ശ്രദ്ധിച്ചില്ല. ഈ ഫോമിൽ, ഒരു ഗ്രൂമിംഗ് സെഷനായി മണിക്കൂറിൽ 5-15 ടിക്കറ്റുകൾ ഇതിനകം ഒരു നല്ല ഫലമായിരുന്നു.

ഞങ്ങൾ ആദ്യം ചെയ്തത് ടീമിനെ പല ഉൽപ്പന്ന ലൈനുകളായി വിഭജിക്കുകയായിരുന്നു. വ്യത്യസ്‌ത വിഭാഗങ്ങൾക്കും സിസ്റ്റങ്ങൾക്കുമായി, ഞങ്ങൾ പ്രത്യേക ടീമുകളെ അനുവദിച്ചു, അതിൽ ഡെവലപ്പർമാർ, ടെസ്റ്റർമാർ, ഉൽപ്പന്ന മാനേജർമാർ, ബിസിനസ് അനലിസ്റ്റുകൾ എന്നിവ ഉൾപ്പെടുന്നു.

തൽഫലമായി, ഞങ്ങൾക്ക് ലഭിച്ചു:

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

ഞങ്ങൾ പ്രധാനമായും കാര്യക്ഷമത, ഉൽപ്പാദനക്ഷമത, ഗുണനിലവാരം എന്നിവയിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചു - ടീമിൻ്റെ പരിവർത്തനത്തിലൂടെ ഞങ്ങൾ പരിഹരിക്കാൻ ശ്രമിച്ച പ്രശ്‌നങ്ങളാണിവ.

പതിനൊന്നാം ദിവസം

ടീം ഘടന മാറ്റുന്ന പ്രക്രിയയിൽ, എങ്ങനെ എണ്ണണമെന്ന് ഞാൻ കണ്ടെത്തി കഥപോയിൻറുകൾ. 1 എസ്പി ഒരു ദിവസത്തിന് തുല്യമായിരുന്നു, ഓരോ ടിക്കറ്റിലും വികസനത്തിനും ക്യുഎയ്ക്കും വേണ്ടിയുള്ള എസ്പി അടങ്ങിയിരിക്കുന്നു, അതായത് കുറഞ്ഞത് 2 എസ്പി.

ഞാൻ ഇത് എങ്ങനെ കണ്ടുപിടിച്ചു?

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

ഇതിനുശേഷം ഞങ്ങൾ:

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

ഇരുപതാം ദിവസം

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

ദീർഘകാല ലക്ഷ്യങ്ങൾ:

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

പണ്ട് പലപ്പോഴും ഇങ്ങനെ പറഞ്ഞിരുന്നു: "നമുക്ക് എല്ലാം [ഭാഷ / ചട്ടക്കൂടിൽ] മാറ്റിയെഴുതാം, എല്ലാം നന്നായി പ്രവർത്തിക്കും!"

മിക്ക കേസുകളിലും ഇത് പ്രവർത്തിക്കുന്നില്ല, റീറൈറ്റ് പ്രവർത്തിക്കുന്നത് നല്ലതാണ്. അതിനാൽ, ഞങ്ങൾക്ക് ഒരു റോഡ്മാപ്പ് സൃഷ്ടിക്കേണ്ടതുണ്ട് - ബിസിനസ്സ് ലക്ഷ്യങ്ങൾ എങ്ങനെ കൈവരിക്കും (ഞങ്ങൾ എന്ത് ചെയ്യും, എന്തുകൊണ്ട്) ഘട്ടം ഘട്ടമായി ചിത്രീകരിക്കുന്ന ഒരു പ്രത്യേക തന്ത്രം:

• പദ്ധതിയുടെ ദൗത്യവും ലക്ഷ്യങ്ങളും പ്രതിഫലിപ്പിക്കുന്നു;
• പ്രധാന ലക്ഷ്യങ്ങൾക്ക് മുൻഗണന നൽകുന്നു;
• അവ നേടുന്നതിനുള്ള ഒരു ഷെഡ്യൂൾ അടങ്ങിയിരിക്കുന്നു.

ഇതിന് മുമ്പ്, എന്തെങ്കിലും മാറ്റങ്ങളുടെ ഉദ്ദേശ്യത്തെക്കുറിച്ച് ആരും ടീമുമായി സംസാരിച്ചിരുന്നില്ല. ഇതിന് ശരിയായ വിജയ മെട്രിക്‌സ് ആവശ്യമാണ്. കമ്പനിയുടെ ചരിത്രത്തിൽ ആദ്യമായി, സാങ്കേതിക ഗ്രൂപ്പിനായി ഞങ്ങൾ കെപിഐകൾ സജ്ജമാക്കി, ഈ സൂചകങ്ങൾ സംഘടനാപരമായവയുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു.

അതായത്, സംഘടനാ കെപിഐകളെ ടീമുകൾ പിന്തുണയ്ക്കുന്നു, ടീം കെപിഐകളെ വ്യക്തിഗത കെപിഐകൾ പിന്തുണയ്ക്കുന്നു. അല്ലെങ്കിൽ, സാങ്കേതിക കെപിഐകൾ സംഘടനാപരമായവയുമായി പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, എല്ലാവരും സ്വയം പുതപ്പ് വലിക്കുന്നു.

ഉദാഹരണത്തിന്, ഓർഗനൈസേഷണൽ കെപിഐകളിലൊന്ന് പുതിയ ഉൽപ്പന്നങ്ങളിലൂടെ വിപണി വിഹിതം വർദ്ധിപ്പിക്കുന്നു.

കൂടുതൽ പുതിയ ഉൽപ്പന്നങ്ങൾ എന്ന ലക്ഷ്യത്തെ നിങ്ങൾക്ക് എങ്ങനെ പിന്തുണയ്ക്കാനാകും?

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

ഗ്രൂപ്പിനുള്ളിൽ എക്സിക്യൂട്ട് ചെയ്യാൻ കഴിയുന്ന വ്യക്തിഗത കെപിഐകൾ, ഉദാഹരണത്തിന്, പ്രധാന വൈകല്യങ്ങൾ വരുന്ന സ്ഥലത്ത് ആയിരിക്കും. നിങ്ങൾ ഈ വിഭാഗത്തിൽ പ്രത്യേകം ശ്രദ്ധ കേന്ദ്രീകരിക്കുകയാണെങ്കിൽ, കുറവുകൾ കുറവാണെന്ന് നിങ്ങൾക്ക് ഉറപ്പാക്കാൻ കഴിയും, തുടർന്ന് പുതിയ ഉൽപ്പന്നങ്ങൾ വികസിപ്പിക്കുന്നതിനും വീണ്ടും ഓർഗനൈസേഷണൽ കെപിഐകളെ പിന്തുണയ്ക്കുന്നതിനുമുള്ള സമയം വർദ്ധിക്കും.

അതിനാൽ, കോഡ് റീറൈറ്റിംഗ് ഉൾപ്പെടെയുള്ള എല്ലാ തീരുമാനങ്ങളും കമ്പനി ഞങ്ങൾക്കായി സജ്ജീകരിച്ചിരിക്കുന്ന നിർദ്ദിഷ്ട ലക്ഷ്യങ്ങളെ (സംഘടനാ വളർച്ച, പുതിയ സവിശേഷതകൾ, റിക്രൂട്ട്‌മെൻ്റ്) പിന്തുണയ്ക്കണം.

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

ദിവസം മുപ്പത്

മാസാവസാനം, ഞാൻ മറ്റൊരു സൂക്ഷ്മത കണ്ടെത്തി: ഞങ്ങളുടെ ഓപ്‌സ് ടീമിലെ ആരും ക്ലയൻ്റുകളുമായി ഞങ്ങൾ നടത്തുന്ന കരാറുകൾ കണ്ടിട്ടില്ല. എന്തുകൊണ്ടാണ് കോൺടാക്റ്റുകൾ കാണേണ്ടത് എന്ന് നിങ്ങൾ ചോദിച്ചേക്കാം.

• ഒന്നാമതായി, SLA-കൾ കരാറുകളിൽ വ്യക്തമാക്കിയിരിക്കുന്നതിനാൽ.
• രണ്ടാമതായി, SLA-കൾ എല്ലാം വ്യത്യസ്തമാണ്. ഓരോ ക്ലയൻ്റും സ്വന്തം ആവശ്യങ്ങളുമായി വന്നു, സെയിൽസ് ഡിപ്പാർട്ട്മെൻ്റ് നോക്കാതെ ഒപ്പിട്ടു.

മറ്റൊരു രസകരമായ സൂക്ഷ്മത, ഏറ്റവും വലിയ ക്ലയൻ്റുകളിലൊരാളുമായുള്ള കരാർ, പ്ലാറ്റ്‌ഫോം പിന്തുണയ്ക്കുന്ന എല്ലാ സോഫ്റ്റ്‌വെയർ പതിപ്പുകളും n-1 ആയിരിക്കണം, അതായത് ഏറ്റവും പുതിയ പതിപ്പല്ല, അവസാനത്തേത്.

കോൾഡ്‌ഫ്യൂഷൻ, എസ്‌ക്യുഎൽ സെർവർ 1 എന്നിവയെ അടിസ്ഥാനമാക്കിയാണ് പ്ലാറ്റ്‌ഫോമെങ്കിൽ, ജൂലൈയിൽ പിന്തുണയ്‌ക്കാത്ത പ്ലാറ്റ്‌ഫോം n-2008-ൽ നിന്ന് എത്ര ദൂരെയാണെന്ന് വ്യക്തമാണ്.

നാൽപ്പത്തിയഞ്ചാം ദിവസം

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

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

ഞാൻ ഇത് ചെയ്തപ്പോൾ, രണ്ട് കാര്യങ്ങൾ എൻ്റെ ശ്രദ്ധയിൽപ്പെട്ടു:

• ക്യുഎയിൽ നിന്ന് ഡെവലപ്പർമാർക്ക് തിരികെ നൽകിയ ടിക്കറ്റുകളുടെ ഉയർന്ന ശതമാനം;
• പുൾ അഭ്യർത്ഥന അവലോകനങ്ങൾക്ക് വളരെയധികം സമയമെടുത്തു.

പ്രശ്‌നം ഇവ പോലുള്ള നിഗമനങ്ങളായിരുന്നു: ഇതിന് വളരെയധികം സമയമെടുക്കുമെന്ന് തോന്നുന്നു, പക്ഷേ എത്ര സമയമെടുക്കുമെന്ന് ഞങ്ങൾക്ക് ഉറപ്പില്ല.

"നിങ്ങൾക്ക് അളക്കാൻ കഴിയാത്തത് മെച്ചപ്പെടുത്താൻ കഴിയില്ല."

പ്രശ്നം എത്ര ഗുരുതരമാണെന്ന് എങ്ങനെ ന്യായീകരിക്കും? ഇത് ദിവസങ്ങളോ മണിക്കൂറുകളോ പാഴാക്കുന്നുണ്ടോ?

ഇത് അളക്കാൻ, ഞങ്ങൾ Jira പ്രോസസ്സിലേക്ക് രണ്ട് ഘട്ടങ്ങൾ ചേർത്തു: ഓരോ ടിക്കറ്റും എത്ര സമയം കാത്തിരിക്കുന്നുവെന്നും ഒരു നിശ്ചിത ഘട്ടത്തിലേക്ക് എത്ര തവണ മടങ്ങുന്നുവെന്നും അളക്കാൻ "dev-ന് തയ്യാറാണ്", "QA-യ്ക്ക് തയ്യാറാണ്".

അവലോകനത്തിനായി ശരാശരി എത്ര ടിക്കറ്റുകൾ ഉണ്ടെന്ന് അറിയാൻ ഞങ്ങൾ "അവലോകനത്തിൽ" ചേർത്തു, ഇതിൽ നിന്ന് നിങ്ങൾക്ക് നൃത്തം ആരംഭിക്കാം. ഞങ്ങൾക്ക് സിസ്റ്റം മെട്രിക്‌സ് ഉണ്ടായിരുന്നു, ഇപ്പോൾ ഞങ്ങൾ പുതിയ മെട്രിക്കുകൾ ചേർത്ത് അളക്കാൻ തുടങ്ങി:

• പ്രക്രിയ കാര്യക്ഷമത: പ്രകടനവും ആസൂത്രണം ചെയ്ത/വിതരണവും.
• പ്രോസസ്സ് നിലവാരം: വൈകല്യങ്ങളുടെ എണ്ണം, ക്യുഎയിൽ നിന്നുള്ള വൈകല്യങ്ങൾ.

എന്താണ് നന്നായി നടക്കുന്നതെന്നും എന്താണ് നല്ലതല്ലെന്നും മനസ്സിലാക്കാൻ ഇത് ശരിക്കും സഹായിക്കുന്നു.

അമ്പതാം ദിവസം

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

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

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

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

ശരിയായ ബാലൻസ് എന്താണ്, അത് എങ്ങനെ നിലനിർത്തണം, എത്ര പേരെ സൂക്ഷിക്കണം, എത്ര തള്ളണം എന്ന ചോദ്യത്തിന് എനിക്ക് നല്ല ഉത്തരം ഇല്ല. ഇത് തികച്ചും വ്യക്തിഗതമായ ഒരു പ്രക്രിയയാണ്.

അമ്പത്തിയൊന്നാം ദിവസം

എനിക്ക് ആരാണെന്ന് മനസിലാക്കാൻ ഞാൻ ടീമിനെ സൂക്ഷ്മമായി നോക്കാൻ തുടങ്ങി, ഒരിക്കൽ കൂടി ഞാൻ ഓർത്തു:

"മിക്ക പ്രശ്നങ്ങളും ആളുകളുടെ പ്രശ്നങ്ങളാണ്."

ടീമിന് - ദേവ്, ഓപ്‌സ് - മൂന്ന് വലിയ പ്രശ്‌നങ്ങളുണ്ടെന്ന് ഞാൻ കണ്ടെത്തി:

• നിലവിലെ അവസ്ഥയിൽ സംതൃപ്തി.
• ഉത്തരവാദിത്തമില്ലായ്മ - കാരണം ബിസിനസിനെ സ്വാധീനിക്കാൻ ആരും പെർഫോമർമാരുടെ പ്രവർത്തനത്തിൻ്റെ ഫലങ്ങൾ കൊണ്ടുവന്നിട്ടില്ല.
• മാറ്റത്തെക്കുറിച്ചുള്ള ഭയം.

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

എന്നാൽ ഒന്നും മാറ്റാതെ നിങ്ങൾക്ക് മെച്ചപ്പെടാൻ കഴിയില്ല.

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

നല്ല ചോദ്യം - എന്തുകൊണ്ട്? ഇപ്പോൾ ഉണ്ടായിരുന്നതിനേക്കാൾ മികച്ചത് പോലെയാണ്, പിന്നെ എല്ലാം നല്ലതു തന്നെ. ഇത് ഉത്തരവാദിത്തത്തിൻ്റെ അഭാവത്തിലേക്ക് നയിക്കുന്നു, ഇത് തത്വത്തിൽ തികച്ചും സാധാരണമാണ്. ഞാൻ പറഞ്ഞതുപോലെ, ടെക്നിക്കൽ ഗ്രൂപ്പ് അൽപ്പം വശത്തായിരുന്നു. അവ നിലനിൽക്കണമെന്ന് കമ്പനി വിശ്വസിച്ചു, പക്ഷേ ആരും ഒരിക്കലും മാനദണ്ഡങ്ങൾ നിശ്ചയിച്ചിട്ടില്ല. സാങ്കേതിക പിന്തുണ ഒരിക്കലും SLA കണ്ടിട്ടില്ല, അതിനാൽ ഇത് ഗ്രൂപ്പിന് തികച്ചും "സ്വീകാര്യമായിരുന്നു" (ഇത് എന്നെ ഏറ്റവും ആകർഷിച്ചു):

• 12 സെക്കൻഡ് ലോഡ് ചെയ്യുന്നു;
• ഓരോ റിലീസിലും 5-10 മിനിറ്റ് പ്രവർത്തനരഹിതമായ സമയം;
• ഗുരുതരമായ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിന് ദിവസങ്ങളും ആഴ്ചകളും എടുക്കും;
• ഡ്യൂട്ടി ജീവനക്കാരുടെ അഭാവം 24x7 / ഓൺ-കോൾ.

എന്തുകൊണ്ടാണ് നമ്മൾ ഇത് നന്നായി ചെയ്യുന്നതെന്ന് ആരും ചോദിക്കാൻ ശ്രമിച്ചില്ല, ഇത് ഇങ്ങനെയാകരുത് എന്ന് ആരും മനസ്സിലാക്കിയിട്ടില്ല.

ഒരു ബോണസ് എന്ന നിലയിൽ, ഒരു പ്രശ്നം കൂടി ഉണ്ടായിരുന്നു: പരിചയക്കുറവ്. മുതിർന്നവർ പോയി, ശേഷിക്കുന്ന യുവ ടീം മുൻ ഭരണത്തിന് കീഴിൽ വളർന്നു, അതിൽ വിഷം കഴിച്ചു.

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

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

അതുകൊണ്ടാണ് ഡെവലപ്പർമാർ എസ്റ്റിമേറ്റുകൾ പെരുപ്പിച്ചുകാട്ടി. അതേ കഥയാണ്, അവർ ഒരു പ്രത്യേക ജോലിയെക്കുറിച്ച് സംസാരിക്കുമ്പോൾ, അവർ എനിക്ക് അത്തരമൊരു രൂപം തന്നത് ഞാൻ വളരെ ആശ്ചര്യപ്പെട്ടു. ഡെവലപ്പറുടെ എസ്റ്റിമേറ്റുകളിൽ, ഡവലപ്പർ QA-യിൽ നിന്ന് ടിക്കറ്റ് തിരികെ നൽകുന്ന സമയം ഉൾപ്പെടുന്നുവെന്ന് എന്നോട് പറഞ്ഞു, കാരണം അവർ അവിടെ പിശകുകൾ കണ്ടെത്തും, PR എടുക്കുന്ന സമയം, ആളുകൾ അവലോകനം ചെയ്യേണ്ട സമയം. അത് തിരക്കിലായിരിക്കും - അതായത്, സാധ്യമായതെല്ലാം.

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

പ്രതികരണമായി, ഞാൻ ഇനിപ്പറയുന്ന രീതികൾ അവതരിപ്പിച്ചു:

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

അറുപതാം ദിവസം

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

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

എന്നാൽ ഡെവലപ്പർമാർക്ക് സെർവറുകൾ വാങ്ങുന്നതിൽ പരിചയവും സെർവറുകളുടെ ആവശ്യമായ വലുപ്പം നിർണ്ണയിക്കുന്നതിനുള്ള വൈദഗ്ധ്യവും ഇല്ല, കാരണം അവർക്ക് മുമ്പ് ഇത് ആവശ്യമില്ല. സ്കേലബിളിറ്റിയും പ്രകടനവും തമ്മിലുള്ള വ്യത്യാസം അവർ സാധാരണയായി മനസ്സിലാക്കുന്നില്ല.

ഇൻവെൻ്ററി ഫലങ്ങൾ:

• ഞങ്ങൾ അതേ ഡാറ്റാ സെൻ്റർ വിട്ടു.
• 3 ലോഗ് സേവനങ്ങളുമായുള്ള കരാർ ഞങ്ങൾ അവസാനിപ്പിച്ചു. കാരണം ഞങ്ങൾക്ക് അവയിൽ 5 എണ്ണം ഉണ്ടായിരുന്നു - എന്തെങ്കിലും ഉപയോഗിച്ച് കളിക്കാൻ തുടങ്ങിയ ഓരോ ഡവലപ്പറും പുതിയൊരെണ്ണം എടുത്തു.
• 7 AWS സിസ്റ്റങ്ങൾ അടച്ചുപൂട്ടി. വീണ്ടും, നിർജീവമായ പദ്ധതികൾ ആരും നിർത്തിയില്ല;
• സോഫ്റ്റ്‌വെയർ ചെലവ് 6 മടങ്ങ് കുറച്ചു.

എഴുപത്തിയഞ്ചാം ദിവസം

സമയം കടന്നുപോയി, രണ്ടര മാസത്തിനുള്ളിൽ എനിക്ക് ഡയറക്ടർ ബോർഡിനെ കാണേണ്ടിവന്നു. ഞങ്ങളുടെ ഡയറക്ടർ ബോർഡ് മറ്റുള്ളവരെക്കാൾ മികച്ചതോ മോശമായതോ അല്ല, എല്ലാ ബോർഡ് ഓഫ് ഡയറക്ടേഴ്സിനെയും പോലെ, അത് എല്ലാം അറിയാൻ ആഗ്രഹിക്കുന്നു. ആളുകൾ പണം നിക്ഷേപിക്കുകയും ഞങ്ങൾ ചെയ്യുന്നത് സെറ്റ് കെപിഐകളുമായി എത്രത്തോളം യോജിക്കുന്നുവെന്ന് മനസിലാക്കാൻ ആഗ്രഹിക്കുകയും ചെയ്യുന്നു.

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

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

ഇക്കാര്യത്തിൽ രസകരമായ ചില പോയിൻ്റുകൾ ഉണ്ടായിരുന്നു. ഉദാഹരണത്തിന്, ഉള്ളടക്കത്തിൻ്റെ തരം അനുസരിച്ച് പ്രത്യേക വെബ് സെർവറുകൾക്കിടയിൽ ട്രാഫിക് വിഭജിക്കണമെന്ന് ഞാൻ പറഞ്ഞു.

അതായത്, ColdFusion ജെട്ടിയിലൂടെയും nginx വഴിയും പോയി പേജുകൾ സമാരംഭിക്കുന്നു. ഇമേജുകളും, JS ഉം CSS ഉം അവരുടേതായ കോൺഫിഗറേഷനുകളുള്ള ഒരു പ്രത്യേക nginx-ലൂടെ കടന്നുപോകുന്നു. ഇത് ഞാൻ സംസാരിക്കുന്നത് തികച്ചും സാധാരണമായ ഒരു സമ്പ്രദായമാണ് എഴുതി കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ്. തൽഫലമായി, ചിത്രങ്ങൾ വളരെ വേഗത്തിൽ ലോഡുചെയ്യുന്നു, കൂടാതെ... ശരാശരി ലോഡിംഗ് വേഗത 200 എംഎസ് വർദ്ധിച്ചു.

ജെട്ടിയിൽ വരുന്ന ഡാറ്റയെ അടിസ്ഥാനമാക്കിയാണ് ഗ്രാഫ് നിർമ്മിച്ചിരിക്കുന്നത് എന്നതിനാലാണ് ഇത് സംഭവിച്ചത്. അതായത്, വേഗത്തിലുള്ള ഉള്ളടക്കം കണക്കുകൂട്ടലിൽ ഉൾപ്പെടുത്തിയിട്ടില്ല - ശരാശരി മൂല്യം ഉയർന്നു. ഇത് ഞങ്ങൾക്ക് വ്യക്തമായിരുന്നു, ഞങ്ങൾ ചിരിച്ചു, പക്ഷേ എന്തുകൊണ്ടാണ് ഞങ്ങൾ എന്തെങ്കിലും ചെയ്തതെന്നും കാര്യങ്ങൾ 12% വഷളായത് എന്തുകൊണ്ടാണെന്നും ഡയറക്ടർ ബോർഡിനോട് എങ്ങനെ വിശദീകരിക്കാനാകും?

എൺപത്തിയഞ്ചാം ദിവസം

മൂന്നാം മാസത്തിൻ്റെ അവസാനത്തിൽ, ഞാൻ ഒരിക്കലും കണക്കാക്കാത്ത ഒരു കാര്യമുണ്ടെന്ന് ഞാൻ മനസ്സിലാക്കി: സമയം. ഞാൻ സംസാരിച്ചതിനെല്ലാം സമയമെടുക്കും.

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

തീരുമാനം

അതുമാത്രമല്ല. ഈ സ്റ്റോറിയിൽ, ഞങ്ങൾ എങ്ങനെ ഉൽപ്പന്നവുമായി പ്രവർത്തിച്ചുവെന്നും പൊതുവായ തരംഗത്തിലേക്ക് ട്യൂൺ ചെയ്യാൻ ശ്രമിച്ചുവെന്നും സാങ്കേതിക പിന്തുണ എങ്ങനെ സമന്വയിപ്പിച്ചുവെന്നും മറ്റ് സാങ്കേതിക പ്രശ്നങ്ങൾ എങ്ങനെ പരിഹരിച്ചുവെന്നും എനിക്ക് മനസ്സിലായില്ല. ഉദാഹരണത്തിന്, ഡാറ്റാബേസിലെ ഏറ്റവും വലിയ പട്ടികകളിൽ ഞങ്ങൾ ഉപയോഗിക്കാത്തത് യാദൃശ്ചികമായി ഞാൻ മനസ്സിലാക്കി SEQUENCE. ഞങ്ങൾക്ക് സ്വയം എഴുതിയ ഒരു പ്രവർത്തനമുണ്ട് nextID, ഇത് ഒരു ഇടപാടിൽ ഉപയോഗിക്കില്ല.

ഞങ്ങൾക്ക് വളരെക്കാലം സംസാരിക്കാൻ കഴിയുന്ന ഒരു ദശലക്ഷം സമാന കാര്യങ്ങൾ കൂടി ഉണ്ടായിരുന്നു. എന്നാൽ ഇപ്പോഴും പറയേണ്ട പ്രധാന കാര്യം സംസ്കാരമാണ്.

സംസ്കാരമോ അതിൻ്റെ അഭാവമോ ആണ് മറ്റെല്ലാ പ്രശ്നങ്ങളിലേക്കും നയിക്കുന്നത്. ആളുകൾ ഉള്ള ഒരു സംസ്കാരം കെട്ടിപ്പടുക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു:

• പരാജയങ്ങളെ ഭയപ്പെടുന്നില്ല;
• തെറ്റുകളിൽ നിന്ന് പഠിക്കുക;
• മറ്റ് ടീമുകളുമായി സഹകരിക്കുക;
• മുൻകൈയെടുക്കുക;
• ഉത്തരവാദിത്തം ഏറ്റെടുക്കുക;
• ഫലത്തെ ഒരു ലക്ഷ്യമായി സ്വാഗതം ചെയ്യുക;
• വിജയം ആഘോഷിക്കുന്നു.

ഇതോടെ മറ്റെല്ലാം വരും.

ലിയോൺ ഫയർ ട്വിറ്ററിൽ, ഫേസ്ബുക്ക് പിന്നെ ഇടത്തരം.

പൈതൃകവുമായി ബന്ധപ്പെട്ട് രണ്ട് തന്ത്രങ്ങളുണ്ട്: എന്ത് വിലകൊടുത്തും അതിനൊപ്പം പ്രവർത്തിക്കുന്നത് ഒഴിവാക്കുക, അല്ലെങ്കിൽ അതുമായി ബന്ധപ്പെട്ട ബുദ്ധിമുട്ടുകൾ ധീരമായി മറികടക്കുക. ഞങ്ങൾ സി DevOpsConf ഞങ്ങൾ രണ്ടാമത്തെ പാത സ്വീകരിക്കുന്നു, പ്രക്രിയകളും സമീപനങ്ങളും മാറ്റുന്നു. ഞങ്ങളോടൊപ്പം ചേരൂ YouTube, അയക്കേണ്ട പട്ടിക и ടെലിഗ്രാം, ഞങ്ങൾ ഒരുമിച്ച് ഒരു DevOps സംസ്കാരം നടപ്പിലാക്കും.

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