ഒരു "സ്റ്റാർട്ടപ്പ്" മുതൽ ഒരു ഡസൻ ഡാറ്റാ സെന്ററുകളിലെ ആയിരക്കണക്കിന് സെർവറുകളിലേക്ക്. ലിനക്സ് ഇൻഫ്രാസ്ട്രക്ചറിന്റെ വളർച്ചയെ ഞങ്ങൾ എങ്ങനെ പിന്തുടർന്നു

നിങ്ങളുടെ ഐടി ഇൻഫ്രാസ്ട്രക്ചർ വളരെ വേഗത്തിൽ വളരുകയാണെങ്കിൽ, താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട് നിങ്ങൾക്ക് ഒരു തിരഞ്ഞെടുപ്പിനെ അഭിമുഖീകരിക്കേണ്ടി വരും: അതിനെ പിന്തുണയ്ക്കുന്നതിനോ ഓട്ടോമേഷൻ ആരംഭിക്കുന്നതിനോ മാനുഷിക വിഭവശേഷി രേഖീയമായി വർദ്ധിപ്പിക്കുക. ഒരു ഘട്ടം വരെ, ഞങ്ങൾ ആദ്യ മാതൃകയിൽ ജീവിച്ചു, തുടർന്ന് ഇൻഫ്രാസ്ട്രക്ചർ-ആസ്-കോഡിലേക്കുള്ള നീണ്ട പാത ആരംഭിച്ചു.

തീർച്ചയായും, NSPK ഒരു സ്റ്റാർട്ടപ്പ് അല്ല, എന്നാൽ അത്തരമൊരു അന്തരീക്ഷം കമ്പനിയിൽ അതിന്റെ അസ്തിത്വത്തിന്റെ ആദ്യ വർഷങ്ങളിൽ ഭരിച്ചു, അവ വളരെ രസകരമായ വർഷങ്ങളായിരുന്നു. എന്റെ പേര് കോർണ്യാക്കോവ് ദിമിത്രി10 വർഷത്തിലേറെയായി ഉയർന്ന ലഭ്യത ആവശ്യകതകളുള്ള Linux ഇൻഫ്രാസ്ട്രക്ചറിനെ ഞാൻ പിന്തുണയ്ക്കുന്നു. 2016 ജനുവരിയിൽ അദ്ദേഹം എൻഎസ്പികെ ടീമിൽ ചേർന്നു, നിർഭാഗ്യവശാൽ, കമ്പനിയുടെ നിലനിൽപ്പിന്റെ തുടക്കം തന്നെ കണ്ടില്ല, പക്ഷേ വലിയ മാറ്റങ്ങളുടെ ഒരു ഘട്ടത്തിലാണ് അദ്ദേഹം വന്നത്.

പൊതുവേ, ഞങ്ങളുടെ ടീം കമ്പനിക്ക് 2 ഉൽപ്പന്നങ്ങൾ വിതരണം ചെയ്യുന്നുവെന്ന് നമുക്ക് പറയാം. ആദ്യത്തേത് അടിസ്ഥാന സൗകര്യങ്ങളാണ്. മെയിൽ പ്രവർത്തിക്കണം, DNS പ്രവർത്തിക്കണം, ക്രാഷ് ചെയ്യപ്പെടാത്ത സെർവറുകളിലേക്ക് ഡൊമെയ്ൻ കൺട്രോളറുകൾ നിങ്ങളെ അനുവദിക്കും. കമ്പനിയുടെ ഐടി ലാൻഡ്‌സ്‌കേപ്പ് വളരെ വലുതാണ്! ഇവ ബിസിനസ്സ് & മിഷൻ ക്രിട്ടിക്കൽ സിസ്റ്റങ്ങളാണ്, ചിലതിന്റെ ലഭ്യത ആവശ്യകതകൾ 99,999 ആണ്. രണ്ടാമത്തെ ഉൽപ്പന്നം സെർവറുകൾ തന്നെയാണ്, ഫിസിക്കൽ, വെർച്വൽ. നിലവിലുള്ളവ നിരീക്ഷിക്കേണ്ടതുണ്ട്, പുതിയവ പല വകുപ്പുകളിൽ നിന്നും ഉപഭോക്താക്കൾക്ക് പതിവായി വിതരണം ചെയ്യണം. ഈ ലേഖനത്തിൽ, സെർവർ ജീവിത ചക്രത്തിന് ഉത്തരവാദിയായ ഇൻഫ്രാസ്ട്രക്ചർ ഞങ്ങൾ എങ്ങനെ വികസിപ്പിച്ചെടുത്തു എന്നതിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

വഴിയുടെ തുടക്കം

ഞങ്ങളുടെ യാത്രയുടെ തുടക്കത്തിൽ, ഞങ്ങളുടെ ടെക്നോളജി സ്റ്റാക്ക് ഇതുപോലെയായിരുന്നു:
OS CentOS 7
FreeIPA ഡൊമെയ്ൻ കൺട്രോളറുകൾ
ഓട്ടോമേഷൻ - അൻസിബിൾ(+ടവർ), കോബ്ലർ

ഇവയെല്ലാം 3 ഡൊമെയ്‌നുകളിലായി, നിരവധി ഡാറ്റാ സെന്ററുകളിലായി വ്യാപിച്ചുകിടക്കുന്നു. ഒരു ഡാറ്റാ സെന്ററിൽ ഓഫീസ് സിസ്റ്റങ്ങളും ടെസ്റ്റ് സൈറ്റുകളും ഉണ്ട്, ബാക്കിയുള്ളതിൽ PROD ഉണ്ട്.

ഒരു ഘട്ടത്തിൽ സെർവറുകൾ സൃഷ്ടിക്കുന്നത് ഇതുപോലെ കാണപ്പെട്ടു:

VM ടെംപ്ലേറ്റിൽ, CentOS വളരെ കുറവാണ്, ആവശ്യമുള്ള മിനിമം ശരിയായ /etc/resolv.conf പോലെയാണ്, ബാക്കിയുള്ളത് Ansible വഴിയാണ് വരുന്നത്.

CMDB - Excel.

സെർവർ ഫിസിക്കൽ ആണെങ്കിൽ, വെർച്വൽ മെഷീൻ പകർത്തുന്നതിനുപകരം, കോബ്ലർ ഉപയോഗിച്ച് അതിൽ OS ഇൻസ്റ്റാൾ ചെയ്തു - ടാർഗെറ്റ് സെർവറിന്റെ MAC വിലാസങ്ങൾ കോബ്ലർ കോൺഫിഗറിലേക്ക് ചേർത്തു, സെർവറിന് DHCP വഴി ഒരു IP വിലാസം ലഭിക്കുന്നു, തുടർന്ന് OS. ചേർത്തിരിക്കുന്നു.

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

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

ഉദാഹരണത്തിന്, എല്ലാ സെർവറുകളിലും ചില കോൺഫിഗറേഷനുകൾ മാറ്റാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു:

1. ലോജിക്കൽ സെഗ്‌മെന്റ്/ഡാറ്റ സെന്ററിലെ നിലവിലുള്ള സെർവറുകളിലെ കോൺഫിഗറേഷൻ ഞങ്ങൾ മാറ്റുന്നു. ചിലപ്പോൾ ഒരു ദിവസത്തിലല്ല - പ്രവേശനക്ഷമത ആവശ്യകതകളും വലിയ സംഖ്യകളുടെ നിയമവും എല്ലാ മാറ്റങ്ങളും ഒരേസമയം പ്രയോഗിക്കാൻ അനുവദിക്കുന്നില്ല. ചില മാറ്റങ്ങൾ വിനാശകരമാകാം, കൂടാതെ എന്തെങ്കിലും പുനരാരംഭിക്കേണ്ടതുണ്ട് - സേവനങ്ങൾ മുതൽ OS വരെ.
2. അൻസിബിളിൽ ഇത് ശരിയാക്കുന്നു
3. ഞങ്ങൾ അത് കോബ്ലറിൽ ശരിയാക്കുന്നു
4. ഓരോ ലോജിക്കൽ സെഗ്‌മെന്റിനും/ഡാറ്റ സെന്ററിനും N തവണ ആവർത്തിക്കുക

എല്ലാ മാറ്റങ്ങളും സുഗമമായി നടക്കുന്നതിന്, നിരവധി ഘടകങ്ങൾ കണക്കിലെടുക്കേണ്ടത് ആവശ്യമാണ്, മാറ്റങ്ങൾ നിരന്തരം സംഭവിക്കുന്നു.

• അൻസിബിൾ കോഡ്, കോൺഫിഗറേഷൻ ഫയലുകൾ റീഫാക്റ്ററിംഗ്
• ആന്തരിക മികച്ച രീതികൾ മാറ്റുന്നു
• സംഭവങ്ങളുടെ/അപകടങ്ങളുടെ വിശകലനത്തിന്റെ ഫലങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ള മാറ്റങ്ങൾ
• ആന്തരികവും ബാഹ്യവുമായ സുരക്ഷാ മാനദണ്ഡങ്ങൾ മാറ്റുന്നു. ഉദാഹരണത്തിന്, PCI DSS എല്ലാ വർഷവും പുതിയ ആവശ്യകതകളോടെ അപ്ഡേറ്റ് ചെയ്യപ്പെടുന്നു

അടിസ്ഥാന സൗകര്യങ്ങളുടെ വളർച്ചയും യാത്രയുടെ തുടക്കവും

സെർവറുകൾ/ലോജിക്കൽ ഡൊമെയ്‌നുകൾ/ഡാറ്റ സെന്ററുകളുടെ എണ്ണം വർദ്ധിച്ചു, കോൺഫിഗറേഷനുകളിലെ പിശകുകളുടെ എണ്ണവും വർദ്ധിച്ചു. ചില ഘട്ടങ്ങളിൽ, കോൺഫിഗറേഷൻ മാനേജ്മെന്റ് വികസിപ്പിക്കേണ്ട മൂന്ന് ദിശകളിലേക്ക് ഞങ്ങൾ എത്തി:

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

കുറച്ച് ഉപകരണങ്ങൾ ചേർക്കാൻ ഇത് ശേഷിക്കുന്നു.

ഞങ്ങളുടെ കോഡ് റിപ്പോസിറ്ററിയായി ഞങ്ങൾ GitLab CE തിരഞ്ഞെടുത്തു, ബിൽറ്റ്-ഇൻ CI/CD മൊഡ്യൂളുകൾക്ക് വേണ്ടിയല്ല.

രഹസ്യങ്ങളുടെ നിലവറ - ഹാഷികോർപ്പ് വോൾട്ട്, ഉൾപ്പെടെ. മഹത്തായ API-യ്‌ക്ക്.

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

ഞങ്ങളുടെ തിരഞ്ഞെടുപ്പ്:

തന്മാത്ര + ടെസ്റ്റിൻഫ്ര
അൻസിബിൾ + ടവർ + AWX
വേൾഡ് ഓഫ് സെർവറുകൾ + DITNET (സ്വന്തം വികസനം)
കോബ്ലർ
Gitlab + GitLab റണ്ണർ
ഹാഷികോർപ്പ് വോൾട്ട്

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

• "ഗോൾഡൻ ഇമേജിൽ" നിന്ന് സെർവറുകൾ പകർത്തുന്നത് തിന്മയാണ്!ഇമേജുകൾ ഇപ്പോൾ ഏത് അവസ്ഥയിലാണെന്ന് നിങ്ങൾക്ക് കൃത്യമായി അറിയില്ല എന്നതാണ് പ്രധാന പോരായ്മ, കൂടാതെ എല്ലാ വിർച്ച്വലൈസേഷൻ ഫാമുകളിലെയും എല്ലാ ചിത്രങ്ങളിലും എല്ലാ മാറ്റങ്ങളും വരും.
• ഡിഫോൾട്ട് കോൺഫിഗറേഷൻ ഫയലുകൾ പരമാവധി ഉപയോഗിക്കുക, പ്രധാന സിസ്റ്റം ഫയലുകളുടെ ഉത്തരവാദിത്തം നിങ്ങൾക്കുള്ള മറ്റ് വകുപ്പുകളുമായി യോജിക്കുകഉദാഹരണത്തിന്:
  1. /etc/sysctl.conf ശൂന്യമായി വിടുക, ക്രമീകരണങ്ങൾ /etc/sysctl.d/ എന്നതിൽ മാത്രമായിരിക്കണം. ഒരു ഫയലിൽ നിങ്ങളുടെ ഡിഫോൾട്ട്, മറ്റൊരു ഫയലിൽ അപ്ലിക്കേഷനായി ഇഷ്‌ടാനുസൃതം.
  2. systemd യൂണിറ്റുകൾ എഡിറ്റ് ചെയ്യാൻ ഓവർറൈഡ് ഫയലുകൾ ഉപയോഗിക്കുക.
• എല്ലാ കോൺഫിഗേഷനുകളും ടെംപ്ലേറ്റ് ചെയ്ത് അവ പൂർണ്ണമായും ഉൾപ്പെടുത്തുക; സാധ്യമെങ്കിൽ, പ്ലേബുക്കുകളിൽ സെഡോ അതിന്റെ അനലോഗോ ഇല്ല
• കോൺഫിഗറേഷൻ മാനേജ്മെന്റ് സിസ്റ്റം കോഡ് റീഫാക്റ്ററിംഗ്:
  1. ചുമതലകളെ ലോജിക്കൽ എന്റിറ്റികളായി വിഭജിക്കുകയും മോണോലിത്തിനെ റോളുകളായി മാറ്റിയെഴുതുകയും ചെയ്യുക
  2. ലിന്ററുകൾ ഉപയോഗിക്കുക! Ansible-lint, yaml-lint മുതലായവ
  3. നിങ്ങളുടെ സമീപനം മാറ്റുക! ബാഷ്‌സിബിൾ ഇല്ല. സിസ്റ്റത്തിന്റെ അവസ്ഥ വിവരിക്കേണ്ടത് ആവശ്യമാണ്
• എല്ലാ അൻസിബിൾ റോളുകൾക്കും നിങ്ങൾ തന്മാത്രയിൽ ടെസ്റ്റുകൾ എഴുതുകയും ദിവസത്തിൽ ഒരിക്കൽ റിപ്പോർട്ടുകൾ സൃഷ്ടിക്കുകയും വേണം.
• ഞങ്ങളുടെ കാര്യത്തിൽ, ടെസ്റ്റുകൾ തയ്യാറാക്കിയ ശേഷം (അതിൽ 100-ലധികം ഉണ്ട്), ഏകദേശം 70000 പിശകുകൾ കണ്ടെത്തി. ഇത് ശരിയാക്കാൻ മാസങ്ങളെടുത്തു.

ഞങ്ങളുടെ നടപ്പാക്കൽ

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

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

സെർവറുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള നിരവധി ഓപ്ഷനുകളും ഉണ്ട്. ഞങ്ങൾ ഇഷ്‌ടാനുസൃത പൈത്തൺ സ്‌ക്രിപ്റ്റുകൾ തിരഞ്ഞെടുക്കുന്നത് അവസാനിപ്പിച്ചു. ഒപ്പം CI അൻസിബിളിനും:

- name: create1.yml - Create a VM from a template
  vmware_guest:
    hostname: "{{datacenter}}".domain.ru
    username: "{{ username_vc }}"
    password: "{{ password_vc }}"
    validate_certs: no
    cluster: "{{cluster}}"
    datacenter: "{{datacenter}}"
    name: "{{ name }}"
    state: poweredon
    folder: "/{{folder}}"
    template: "{{template}}"
    customization:
      hostname: "{{ name }}"
      domain: domain.ru
      dns_servers:
        - "{{ ipa1_dns }}"
        - "{{ ipa2_dns }}"
    networks:
      - name: "{{ network }}"
        type: static
        ip: "{{ip}}"
        netmask: "{{netmask}}"
        gateway: "{{gateway}}"
        wake_on_lan: True
        start_connected: True
        allow_guest_control: True
    wait_for_ip_address: yes
    disk:
      - size_gb: 1
        type: thin
        datastore: "{{datastore}}"
      - size_gb: 20
        type: thin
        datastore: "{{datastore}}"

ഇതാണ് ഞങ്ങൾ എത്തിയിരിക്കുന്നത്, സിസ്റ്റം ജീവിക്കുകയും വികസിക്കുകയും ചെയ്യുന്നു.

• 17 സെർവർ സജ്ജീകരിക്കുന്നതിനുള്ള പ്രധാന റോളുകൾ. ഓരോ റോളുകളും ഒരു പ്രത്യേക ലോജിക്കൽ ടാസ്‌ക് (ലോഗിംഗ്, ഓഡിറ്റിംഗ്, ഉപയോക്തൃ അംഗീകാരം, നിരീക്ഷണം മുതലായവ) പരിഹരിക്കുന്നതിന് രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു.
• റോൾ ടെസ്റ്റിംഗ്. തന്മാത്ര + ടെസ്റ്റ് ഇൻഫ്രാ.
• സ്വന്തം വികസനം: CMDB + ഓർക്കസ്ട്രേറ്റർ.
• സെർവർ സൃഷ്ടിക്കൽ സമയം ~30 മിനിറ്റാണ്, ഓട്ടോമേറ്റഡ്, ടാസ്ക് ക്യൂവിൽ നിന്ന് പ്രായോഗികമായി സ്വതന്ത്രമാണ്.
• എല്ലാ സെഗ്‌മെന്റുകളിലും അടിസ്ഥാന സൗകര്യങ്ങളുടെ ഒരേ അവസ്ഥ/നാമകരണം - പ്ലേബുക്കുകൾ, റിപ്പോസിറ്ററികൾ, വിർച്ച്വലൈസേഷൻ ഘടകങ്ങൾ.
• സ്റ്റാൻഡേർഡുമായുള്ള പൊരുത്തക്കേടുകളെക്കുറിച്ചുള്ള റിപ്പോർട്ടുകൾ സൃഷ്ടിക്കുന്നതിനൊപ്പം സെർവർ നിലയുടെ പ്രതിദിന പരിശോധന.

യാത്രയുടെ തുടക്കത്തിലിരിക്കുന്നവർക്ക് എന്റെ കഥ ഉപയോഗപ്രദമാകുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. ഏത് ഓട്ടോമേഷൻ സ്റ്റാക്കാണ് നിങ്ങൾ ഉപയോഗിക്കുന്നത്?

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