എന്തുകൊണ്ടാണ് ഒരു ബാങ്കിന് AIO-കളും കുട നിരീക്ഷണവും ആവശ്യമായി വരുന്നത്, അല്ലെങ്കിൽ ഉപഭോക്തൃ ബന്ധങ്ങൾ എന്തിനെ അടിസ്ഥാനമാക്കിയാണ്?

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

ഞാൻ നിലവിൽ MONQ ഡിജിറ്റൽ ലാബ് എന്ന സ്റ്റാർട്ടപ്പിന്റെ തലവനാണ്, അവിടെ ഞാനും എന്റെ ടീമും കോർപ്പറേറ്റ് ഐടിയെ പിന്തുണയ്ക്കുന്നതിനും പ്രവർത്തിപ്പിക്കുന്നതിനുമുള്ള പ്രക്രിയകൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനുള്ള ഒരു ഉൽപ്പന്നം വികസിപ്പിക്കുകയാണ്. വിപണിയിൽ പ്രവേശിക്കുന്നത് എളുപ്പമുള്ള കാര്യമല്ല, ഞങ്ങൾ ഒരു ചെറിയ ഗൃഹപാഠത്തോടെ ആരംഭിച്ചു, മാർക്കറ്റ് വിദഗ്ധർ, ഞങ്ങളുടെ പങ്കാളികൾ എന്നിവയിലൂടെ സഞ്ചരിച്ച് വിപണി വിഭജനം നടത്തി. “ആരുടെ വേദനകളാണ് നമുക്ക് നന്നായി സുഖപ്പെടുത്താൻ കഴിയുക?” എന്നതായിരുന്നു പ്രധാന ചോദ്യം.

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

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

ഞങ്ങൾ നിർമ്മിക്കുന്ന ഉൽപ്പന്നം എന്റർപ്രൈസ് സോഫ്‌റ്റ്‌വെയർ, AIOps (ആർട്ടിഫിഷ്യൽ ഇന്റലിജൻസ് ഫോർ ഐടി ഓപ്പറേഷൻസ് അല്ലെങ്കിൽ ITOps) വിഭാഗത്തിൽ പെട്ടതാണ്. കമ്പനിയിലെ പ്രോസസ്സ് മെച്യൂരിറ്റിയുടെ തോത് വർദ്ധിക്കുന്നതിനാൽ അത്തരം സംവിധാനങ്ങൾ നടപ്പിലാക്കുന്നതിന്റെ പ്രധാന ലക്ഷ്യങ്ങൾ:

1. തീ കെടുത്തുക: പരാജയങ്ങൾ തിരിച്ചറിയുക, അവശിഷ്ടങ്ങളിൽ നിന്ന് അലേർട്ടുകളുടെ സ്ട്രീം മായ്‌ക്കുക, ഉത്തരവാദിത്തപ്പെട്ടവർക്ക് ചുമതലകളും സംഭവങ്ങളും നൽകുക;
2. ഐടി സേവനത്തിന്റെ കാര്യക്ഷമത വർദ്ധിപ്പിക്കുക: സംഭവങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള സമയം കുറയ്ക്കുക, പരാജയങ്ങളുടെ കാരണങ്ങൾ സൂചിപ്പിക്കുക, ഐടി നിലയുടെ സുതാര്യത വർദ്ധിപ്പിക്കുക;
3. ബിസിനസ്സ് കാര്യക്ഷമത വർദ്ധിപ്പിക്കുക: സ്വമേധയാലുള്ള ജോലിയുടെ അളവ് കുറയ്ക്കുക, അപകടസാധ്യതകൾ കുറയ്ക്കുക, ഉപഭോക്തൃ വിശ്വസ്തത വർദ്ധിപ്പിക്കുക.

ഞങ്ങളുടെ അനുഭവത്തിൽ, എല്ലാ വലിയ ഐടി ഇൻഫ്രാസ്ട്രക്ചറുകളുമായും പൊതുവായ നിരീക്ഷണത്തിൽ ബാങ്കുകൾക്ക് ഇനിപ്പറയുന്ന "വേദനകൾ" ഉണ്ട്:

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

ടിങ്കോഫിലെ ആദ്യ മീറ്റിംഗിൽ ഞങ്ങൾ എത്തിയപ്പോൾ, അവർക്ക് നിരീക്ഷണത്തിൽ പ്രശ്‌നങ്ങളൊന്നുമില്ലെന്നും അവരെ വേദനിപ്പിക്കുന്നതൊന്നും ഇല്ലെന്നും ഞങ്ങളോട് പറഞ്ഞു, പ്രധാന ചോദ്യം ഇതായിരുന്നു: “ഇതിനകം നന്നായി പ്രവർത്തിക്കുന്നവർക്ക് ഞങ്ങൾക്ക് എന്താണ് വാഗ്ദാനം ചെയ്യാൻ കഴിയുക?”

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

വഴിയിൽ, ബാങ്കിന്റെ SLA-കൾ ശരിക്കും ശ്രദ്ധേയമാണ്. ഉദാഹരണത്തിന്, മുൻ‌ഗണനയുള്ള XNUMX നെറ്റ്‌വർക്ക് ലഭ്യത സംഭവം പരിഹരിക്കാൻ കുറച്ച് മിനിറ്റുകൾ മാത്രം എടുത്തേക്കാം. ഇവിടെ പിശകിന്റെയും പ്രവർത്തനരഹിതമായ സമയത്തിന്റെയും വില തീർച്ചയായും ശ്രദ്ധേയമാണ്.

തൽഫലമായി, സഹകരണത്തിന്റെ നിരവധി മേഖലകൾ ഞങ്ങൾ തിരിച്ചറിഞ്ഞു:

1. സംഭവ പരിഹാരത്തിന്റെ വേഗത വർദ്ധിപ്പിക്കുന്നതിനുള്ള കുട നിരീക്ഷണമാണ് ആദ്യ ഘട്ടം
2. അപകടസാധ്യതകൾ കുറയ്ക്കുന്നതിനും ഐടി ഡിപ്പാർട്ട്‌മെന്റിന്റെ സ്കെയിലിംഗ് ചെലവുകൾ കുറയ്ക്കുന്നതിനുമുള്ള പ്രോസസ്സ് ഓട്ടോമേഷനാണ് രണ്ടാം ഘട്ടം.

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

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

പൈലറ്റ് പ്രോജക്റ്റ് ആരംഭിച്ചു, അതിന്റെ അതിരുകൾ നിർണ്ണയിക്കുകയും ഞങ്ങൾക്ക് 2 മാസം നൽകുകയും ചെയ്തു. പ്രധാന ജോലികൾ ഇവയായിരുന്നു:

• പ്ലാറ്റ്‌ഫോമിന്റെ ഒരു പുതിയ പതിപ്പ് തയ്യാറാക്കി ബാങ്കിന്റെ ഇൻഫ്രാസ്ട്രക്ചറിൽ വിന്യസിക്കുക
• 2 മോണിറ്ററിംഗ് സിസ്റ്റങ്ങൾ ബന്ധിപ്പിക്കുക (Zabbix, Prometheus);
• Slack-ലും SMS വഴിയും ഉത്തരവാദിത്തപ്പെട്ടവർക്ക് അറിയിപ്പുകൾ അയയ്ക്കുക;
• ഓട്ടോഹീലിംഗ് സ്ക്രിപ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുക.

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

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

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

എന്നാൽ ഞങ്ങൾക്ക് കൃത്യമായി ഒരു മാസം ശേഷിക്കുന്നു, ഈ സമയത്ത് ഞങ്ങൾക്ക് എല്ലാം ഇൻസ്റ്റാൾ ചെയ്യുകയും ഓട്ടോമേഷൻ കോൺഫിഗർ ചെയ്യുകയും വിന്യസിക്കുകയും ചെയ്യേണ്ടതുണ്ട്.

ഞങ്ങളുടെ ചീഫ് ആർക്കിടെക്റ്റായ സെർജിയുടെ അഭിപ്രായത്തിൽ, പ്ലഗ്-ഇൻ സംവിധാനം നടപ്പിലാക്കാൻ കുറഞ്ഞത് ഒരു മാസമെങ്കിലും എടുക്കും.

ഞങ്ങൾക്ക് സമയമില്ലായിരുന്നു...

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

പൈലറ്റിന്റെ ഫലമായി, നിരവധി പ്രധാന സാങ്കേതിക ഫലങ്ങളും നിഗമനങ്ങളും ലഭിച്ചു:

അലേർട്ടുകൾ പ്രോസസ്സ് ചെയ്യുന്നതിനുള്ള പുതിയ പ്രവർത്തനം ഞങ്ങൾ പരീക്ഷിച്ചു

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

"സിന്തറ്റിക് ട്രിഗർ" ഇന്റർഫേസ്. ബന്ധിപ്പിച്ച മോണിറ്ററിംഗ് സിസ്റ്റങ്ങളിൽ നിന്നുള്ള അലേർട്ടുകളുടെ പ്രോസസ്സിംഗ് സജ്ജീകരിക്കുന്നു

സിസ്റ്റത്തിന്റെ "ആരോഗ്യം" എന്ന അവസ്ഥ നിർമ്മിച്ചു

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

റിസോഴ്സ്-സർവീസ് മോഡലുമായി പ്രവർത്തിക്കുന്നതിനുള്ള ഇന്റർഫേസ്. പൈലറ്റ് ആർഎസ്എം.

ശരി, വാസ്തവത്തിൽ, ക്ലയന്റിന് ഒടുവിൽ ഒരൊറ്റ മോണിറ്ററിംഗ് സ്ക്രീൻ ഉണ്ട്, അവിടെ വ്യത്യസ്ത സിസ്റ്റങ്ങളിൽ നിന്നുള്ള ഇവന്റുകൾ ദൃശ്യമാകും. നിലവിൽ, രണ്ട് സിസ്റ്റങ്ങൾ “കുട” യുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു - Zabbix, Prometheus, കൂടാതെ പ്ലാറ്റ്‌ഫോമിന്റെ തന്നെ ഒരു ആന്തരിക നിരീക്ഷണ സംവിധാനം.

അനലിറ്റിക്സ് ഇന്റർഫേസ്. ഒറ്റ മോണിറ്ററിംഗ് സ്ക്രീൻ.

പ്രോസസ്സ് ഓട്ടോമേഷൻ ആരംഭിച്ചു

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

പ്രവർത്തന ക്രമീകരണ ഇന്റർഫേസ്. സ്ലാക്കിലേക്ക് അലേർട്ടുകൾ അയച്ച് സെർവർ റീബൂട്ട് ചെയ്യുക.

വിപുലീകരിച്ച ഉൽപ്പന്ന പ്രവർത്തനം

ഓട്ടോമേഷൻ സ്ക്രിപ്റ്റുകൾ ചർച്ച ചെയ്യുമ്പോൾ, ക്ലയന്റ് ബാഷ് പിന്തുണയും ഈ സ്ക്രിപ്റ്റുകൾ സൗകര്യപ്രദമായി ക്രമീകരിക്കാൻ കഴിയുന്ന ഒരു ഇന്റർഫേസും ആവശ്യപ്പെട്ടു. പുതിയ പതിപ്പ് കുറച്ച് കൂടി (CURL, SSH, SNMP എന്നിവയ്‌ക്കുള്ള പിന്തുണയോടെ ലുവായിൽ പൂർണ്ണമായ ലോജിക്കൽ നിർമ്മാണങ്ങൾ എഴുതാനുള്ള കഴിവ്) കൂടാതെ ഒരു സ്‌ക്രിപ്റ്റിന്റെ ജീവിത ചക്രം (സൃഷ്ടിക്കുക, എഡിറ്റ് ചെയ്യുക, പതിപ്പ് നിയന്ത്രണം) നിയന്ത്രിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന പ്രവർത്തനം നടപ്പിലാക്കി. , ഇല്ലാതാക്കുക, ആർക്കൈവ് ചെയ്യുക).

ഓട്ടോഹീലിംഗ് സ്ക്രിപ്റ്റുകളിൽ പ്രവർത്തിക്കുന്നതിനുള്ള ഇന്റർഫേസ്. SSH വഴി സെർവർ റീബൂട്ട് സ്ക്രിപ്റ്റ്.

പ്രധാന കണ്ടെത്തലുകൾ

പൈലറ്റ് സമയത്ത്, നിലവിലെ പ്രവർത്തനക്ഷമത മെച്ചപ്പെടുത്തുന്നതിനും ക്ലയന്റിനുള്ള മൂല്യം വർദ്ധിപ്പിക്കുന്നതിനും ഉപയോക്തൃ സ്റ്റോറികൾ സൃഷ്ടിക്കപ്പെട്ടു, അവയിൽ ചിലത് ഇതാ:

• അലേർട്ടിൽ നിന്ന് ഓട്ടോഹീലിംഗ് സ്ക്രിപ്റ്റിലേക്ക് നേരിട്ട് വേരിയബിളുകൾ കൈമാറാനുള്ള കഴിവ് നടപ്പിലാക്കുക;
• ആക്റ്റീവ് ഡയറക്ടറി വഴി പ്ലാറ്റ്‌ഫോമിലേക്ക് അംഗീകാരം ചേർക്കുക.

ഞങ്ങൾക്ക് കൂടുതൽ ആഗോള വെല്ലുവിളികൾ ലഭിച്ചു - മറ്റ് കഴിവുകൾ ഉപയോഗിച്ച് ഉൽപ്പന്നം "ബിൽഡ് അപ്പ്" ചെയ്യാൻ:

• നിയമങ്ങൾക്കും ഏജന്റുമാർക്കും പകരം ML അടിസ്ഥാനമാക്കിയുള്ള ഒരു റിസോഴ്സ്-സർവീസ് മോഡലിന്റെ യാന്ത്രിക നിർമ്മാണം (ഒരുപക്ഷേ ഇപ്പോൾ പ്രധാന വെല്ലുവിളി);
• അധിക സ്ക്രിപ്റ്റിംഗിനും ലോജിക് ഭാഷകൾക്കുമുള്ള പിന്തുണ (ഇത് JavaScript ആയിരിക്കും).

എന്റെ അഭിപ്രായത്തിൽ ഏറ്റവും പ്രധാനപ്പെട്ടഈ പൈലറ്റ് കാണിക്കുന്നത് രണ്ട് കാര്യങ്ങളാണ്:

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

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