Category: Експлоатация

Домашен дейтацентър или лаборатория|HomeLab, Home Data center

Много devops, програмисти, системни и мрежови администратори изграждат свои домашни лаборатории, мини дейтацентрове, включително доста амбициозни и сериозно направени системи…

В тази статия разглеждам някои от съществените лимити, с които следва да се съобразяваме в амбициите и инвестициите си.

Тъй като е удобно и дори изглежда изгодно да натоварим домашната си лаборатория със сериозни задачи (например проекти за клиенти) – изхождайки от опита си за проектиране и изграждане на сериозна домашна лаборатория (от клас мини дейта център :), споделям лош опит, в желанието си да спестя на читателя настъпването на някоя и друга мотика по пътя. 😉

1. Не правете голяма инвестиция – в крайна сметка домашната лаборатория е за тестове и PoC (Proof of Concept), използването и за други цели рано или късно води до задънена улица и по някое време ще се наложи да отпишете инвестираното и направите нещата както трябва.
Все пак, по-долу (т. 7.) описвам добра (макар не изключителна) идея, която може да осмисли сериозното използване на домашната инфраструктура.

Така че – инвестирайте разумно и пестеливо, за да не загубите много (пари, време, нерви, недоволни клиенти и пропуснати възможности).

2. Причината да отпишете инвестицията е, че домашният дейтацентър не скалира добре – нито в посока повече оборудване, но винаги ще е зле в посока отказоустойчивост и надеждност на работата.

Винаги! Винаги!!

Дали съм достатъчно категоричен?

Винаги!!!

3. Имайте предвид, че много рядко електрическите инсталации в стандартните жилища са оразмерени добре, за да поддържат
7 x 24 x 365 дори малки товари от 1-2KW. Това не винаги се забелязва и никога не е проблем в началото, но е добре да се провери след няколко месеца работа дали предпазителите и изходните шини не греят. Следващите индикатори са черни конвективни следи над таблото, миризма на изгоряло и вой на пожарни сирени.

4. Проблемите с шума са добре известни и всеки чувал стартиращ или натоварен сървър има ясна звукова представа за тях. :). Ще добавя само, че шумът от вентилаторите на средномощен сървър, в някои сгради се чува и през нощта, включително И от съседите.
Разбира се, те не са чак такъв проблем, но помислете за отношенията си с партньора… 🙂  

5. Охлаждането – няма лесен и смислен начин да направите добро охлаждане, ако ще имате повече сървъри. Студеният въздух трябва да се движи отдолу нагоре и фронт/гръб спрямо сървърите (ако са за рак монтаж). Това, което можете да направите е да държите достатъчно ниска температурата в помещението, за да осигурите генерално температурния режим на оборудването, но тази схема консумира повече енергия и поради това е ценово неефективна.

Е, ако имате достатъчно средства може да заложите на рак със собствена климатизация, но това е инвестиция, която не си струва предвид описаното в т. 2.

6. Възможните компромиси –

– Ако просто имате нужда от домашен лаб – използвайте втора ръка мобилни работни станции – те дават доста мощност и са относително тихи (стига да не спите в едно и също помещение с тях). Предимствата им – не ви трябва UPS или KVM имате си вградени монитор, мишка и клавиатура.

– За ML (Machine Learning) – сглобете си машина с големи бавни вентилатори, не повече от един, но възможно най-мощен ускорител, например NVidia GeForce RTX 2080Ti. Пак ще шуми, но ако е в съседно помещение се търпи. Или не се търпи – зависи…

7. Направете си (или използвайте “as a service”) мониторинг – като минимум – температура на околната среда и на системите – трябва да знаете температурното им състояние и да получавате известия при надвишаване на допустимите рамки.

Разбира се мониторинга е необходим и за други цели – например: параметри на експлоатация, надеждност, сигурност, контрол на SLA.

Хубавото в тази схема е, че когато прехвърлите проектите си, където им е мястото – тогава домашната инфраструктура може да се използва за независим (или втори) мониторинг.

8. Ако правилно изберете оркестрацията на виртуализация/контейнеризация – ще можете лесно да мигрирате приложенията си към ваши ресурси в частни или публични клауд платформи. Така ще си запазите възможноста да правите бързи и евтини тестове и PoC в домашната среда, същевременно ще можете лесно да мигрирате продакшън системите на правилните платформи.

9. Спестете си проблеми със сигурността и надеждността и разделете правилно инфраструктурата за тестове и PoC от домашния си интернет, не ги смесвайте от самото начало най-добре – т.е. организирайте си файъруол (може и виртуализиран, но с много мисъл), умен суич/и.

Повтарям – от самото начало разделете едното от другото, никакъв компромис, временно решение и прочие.

Home Office – Дистанционна работа – съвети, решения, опит

Резюме

Пандемията COVID-19 стана причина за бурно преминаване към така наречения home office (домашен офис, remote office, remote working и т.н.). Много компании, особено работещи в областта на информационните технологии и BPO (Business Process Oursourcing) бяха подготвени и кризисната реакция протече гладко. Други компании потърсиха и имплементираха решения в спешен порядък, при което основен фокус бе навременното осигуряване възможността за отдалечена работа. 

Home office представлява сериозно предизвикателство, а някои подценени аспекти на сигурността създават предпоставки за бъдещи проблеми. 

Целта на документа е да дефинира обща методологична и организационна рамка за изграждане и експлоатация на инфраструктура за отдалечена работа, както и насочване вниманието на мениджмънта към правилната организация на работния процес. 

Посочени са конкретни open source технологии и решения за изграждане и поддръжка на инфраструктура за дистанционна работа, но съветите и споделените добри практики са валидни за целия спектър на възможните, включително комерсиални решения. 

Принципи
Предварителна подготовка

Възможността за отдалечена работа се свежда до решаване на следните задачи на ниво организация и IT ресурси – 

  • Технология за създаване на роли, групи и потребители
    • Управление на фирмената IT сигурност чрез правилно проектиране нивата на достъп до фирмените ресурси
    • Дефиниране на потребителските роли
    • Разпределяне на правата по роли и групи потребители
  • Процес за управление на автентикация и оторизация на потребителите
  • Осигуряване на достъп до чрез VPN технология до фирмените ресурси
  • Контролиране на достъпа
  • Наблюдение, детекция на подозрително поведение, управление на инциденти свързани със сигурността

Доколкото във фирмите с развита IT инфраструктура, изброените проблеми и задачи са решени на локално ниво (т.е. вътре във формения офис), то накратко ще опишем технологично решение за отдалечена работа за малки фирми, не разполагащи със съответната инфраструктура, а след това ще се фокусираме върху общите предизвикателства и добри практики, гарантиращи сигурност и ефективност на отдалечената работа.  

Организация и управление на работния процес

За успешната отдалечена работа е необходимо да:

  • Организационни решения
    • Организирате управление на отдалечения достъп със съответните потребителски имена, пароли и сертификати за криптиране на комуникацията
    • Предварително определена и форсирана стратегия за управление на отдалечения достъп до фирмените ресурси

 

  •  
  • Технологични решения
    • Разполагате с механизъм потребителите самостоятелно да възстановяват забравени пароли
    • Разполагате с написана и добре структурирана помощна информация и екип в състояние да обучи потребителите и да ги поддържа в процеса на работа
    • Предварително конфигурирана и тествана в офиса свързаност към фирмения VPN сървър, за да се избегне ситуация за решаване на проблеми в момент, когато потребителите преминат към отдалечена работа от домовете си
    • Предварително инсталирани антивирусни програми
    • Предварително инсталирани системи за Host based Intrusion Detection, защитаващи критични системни файлове и директории
    • Предварително организирана система за събиране, анализ и реакция при критични събития 

 

Сигурност

Въпреки, че сигурността е част от работния процес, отделяме специално внимание на темата, защото инкубационният период на проблемите породени от бързо и недостатъчно добре планирано преминаване към режим на отдалечена работа е дълъг и това е предпоставка за сериозно компрометиране на фирмената и в частност информационна сигурност.

 

Технологии и решения с отворен код
Управление на потребители

Може да се използва LDAP или Active directory за управление на потребителски роли и групи. Извън екосистемата на Майкрософт решенията, може да се използва open source Samba Server като файлов, принт и сървър за управление на потребители в уиндоус или уеб базирана среда. 

Възможни open source решения –

VPN концентратор / сървър

Съществуват няколко широко използвани технологии, например – IPSEC или OpenVPN. Доколкото IPSEC се поддържа без инсталация на допълнителни клиенти в Windows, той изглежда естествена технологичен избор за уиндоус среда.

Лично аз препоръчвам като оптимален вариант OpenVPN, заради по-голямата гъвкавост и универсалност. Повече аргументация можете да намерите в статията тук: OpenVPN.

Ако организацията не разполага с наличен VPN концентратор, включително комерсиални решения от различни доставчици на мрежoв хардуер, като Cisco, Juniper, Fortinet, HP, Aruba, Ubiquiti, Mikrotik и много други, можете да изградите VPN решение от висок клас, базирано на софтуер с отворен код PfSense – представлява Firewall, VPN Concentrator, Intrusion Detection System, Intrusion Prevention System от най-висок клас. 

Решения за комуникация на служителите

Комуникацията между служителите (също и с клиентите) е интегриран елемент от организацията на отдалечената работа. Тук фокусът е към приложенията за онлайн съобщения – chat, а не към мейл – утвърдено, но според някои – остаряло решение за бизнес комуникация.

Обикновено фирмите разполагат с де факто механизъм, който може да е общо фирмено решение или изборът на комуникационна технология да е оставен в ръцете на обикновените потребители и в рамките на отдели и работни групи. 

Макар комерсиалните решения да имат някои преимущества, няма някакви съществени разлики, спрямо решенията с отворен код. Всъщност основна причина да използвате комерсиални решения е съвместимост с клиенти, които са инвестирали в тези технологии, но дори това не е особено огрничаващ фактор.  

Популярни средства са:

Групуеър решение за споделена работа

NextCloud е групуеър (groupware) платформа с отворен код, функционално подобна на Dropbox или Google Drive. Позволява изграждане на независима и безплатна платформа за споделяне на файлове, календар, контакти и съвместна работа върху файлове на ниво организация или по-малка работна група.

Към НексКлауд може да се интегрират уеб базирани офис приложения, например Only Office, което дава възможност за уеб базирана съвместна работа с документи (подобно на Google Drive или Offie365).

Има относително добра съвместимост с MS Office – т.е. Next Cloud + Only Office отваря и визуализира на приемливо ниво документи създадени с MS Office, респективно документите създадени през Only Office са съвместими с MS Office.  

Система за управление и контрол на сигурността

Възможността за отдалечена работа предтавлява изключителен риск за сигурността на организацията. Използването на технически средства за изграждане и гарантиране на сигурността е задължително, а използването на интегрирано решение, което съчетава както събирането, анализа на информация свързана със сигурността и механизми за реакция при инцидент – е силно препоръчително. 

Нашият избор е AlienVault OSSIM – система с отворен код, интегрираща набор от инструменти, предназначени да подпомогнат процеса на поддръжка на информационната сигурност – откриването, управление на последици и предотвратяване на прониквания. Повече информация в статията –  AlienVault OSSIM

 

Съвети към IT мениджъра:
  • Организацията на възможност за отдалечена работа е свързана с два компонента
    • Ефективност на работата – т.е. контрол на производителността на служителите
    • Информационна сигурност 
  • Никога не считайте, че използването на каквато и да е технология за защита, е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

Експлоатация на сървъри. Част 1. Натоварване

  • Кое е оптималното натоварване на един сървър?
  • Под какво натоварване може да смятаме, че инфраструктурата се използва неефективно?
  • Над какво натоварване считаме, че сървърът е претоварен?

В тази статия ще дам някои насоки и възможни отговори. IT инфраструктурата е комплекс от много взаимозависимости и няма еднозначен отговор. Освен това натоварването само по себе си не е проблем, проблем са страничните ефекти от него.

Винаги, когато планираме и експлоатираме IT инфраструктура (за целите на статията нека разглеждаме уеб сървър), следва да отчитаме TCO (Total Cost of Ownership) като параметър. Като пример за важността – в рамките на средностатистическия полезен живот на хардуера, управлението на електрическата консумация е съществена необходимост (грубо може да се приеме, че 10% от свързания оперативен разход подлежи на оптимизация).

Изключително важно е да си осигурим добра видимост към инфраструктурата, което предполага тотален (но разумен и не изкривяващ профила на натоварването) мониторинг върху работата на системите. Добрият мониторинг дава възможност за предвиждане и изследване потенциалните проблеми още преди да сме стигнали до етапа на продукция.

Нещата са кардинално различни, ако ги оценяваме в клауд инфраструктура (т.е. имаме чиста себестойност от тип „сървис като инфраструктура“) или уебсървъра работи върху „собствен“ сървър, консумиращ „собствено“ електричество и топлоотделящ в „собственото“ помещение, което отново „собствено“ охлаждаме. На тази тема ще посветя една от следващите статии.

TCO зависи от хардуера и начина, по който го експлоатираме. Най-силна и видима е зависимостта от броя и типа сървърни захранвания. Това е така, защото ефективността на захранването е най-висока, ако натоварването му е над 60% и оптимална при ~80%.

Ако сървърът е слабо натоварен, с малко памет и дискове – консумацията му е ниска и ако използва две балансиращи натоварването захранвания – то всяко от тях ще работи извън оптималния си режим.

  • В този случай е необходимо ръчно конфигуриране за работа в режим hot/cold stand-by на едно от захранванията
  • Така другото ще се натовари повече и ще работи в оптималните граници
  • По-новите сървъри поддържат автоматизирано управление на консумацията, но е необходимо да са включени в съответния режим (обикновено не е по подразбиране)

От гледна точка разходи за електричество – колкото повече натоварите сървъра – толкова по-добре, стига системата да се държи предвидимо. Друга зависимост се проявява в случаите, когато сървърът работи върху bare metal или виртуализиран хардуер. Ако е виртуализиран, хайпървайзъра ще се погрижи голямо натоварване (70%+) на сървъра да не се отрази (в някакви граници) на латентността на другите виртуализирани услуги.

Някои конкретни съвети

Насочени са основно към системни администратори и devops. Всъщност препоръчително е CIO и IT мениджърите да са наясно с материята, доколкото TCO и качеството на услугите са тяхна отговорност.

  • Някои комбинации сървърен софтуер (например Apache/PHP) предизвикват и въобще са чувствителни към латентност. Не допускайте в продукция всичко да зависи от фронтенд перманентно натоварен над, да речем, 50%, защото:
    • Няма място за реакция на инцидентни (пикови натоварвания)
    • Влияе и усложнява откриването на други свързани или несвързани проблеми
    • В крайна сметка усложнява и оскъпява експлоатацията на цялостната система
  • Планирайте и от самото начало използвайте лоудбалансър(и) и поне два фронтенда
    • Може да бъдат виртуализирани напълно или да се използва хибридна схема за оптимално TCO
    • Когато натоварването нарастне, за да си струва – тогава може да преминете към bare metal хардуер
  • В общи линии най-изгодно е инфраструктурата да е виртуализирана (контейнеризирана в частност)
  • Контролирайте (по възможност) архитектурата на приложението и качествения код на разработчиците
  • По възможност (особено, ако разработвате бизнес критични системи) избягвайте да съчетавате множество функции в един сървър (например уеб, дейтабейс, файлов и прочие)
    • Ако това не е възможно – оставете достатъчно резерв например средно натоварване на сървърен процес под 20% (за да имате резерв за абсорбиране на пикови натоварвания)
    • Не лош вариант е да управлявате прецизно натоварването в рамките на един сървър с cgroups, но е доста времеемко, а крайният резултат не винаги е достатъчен и често проблемите само се отлагат за известно време

В тази връзка препоръчваме виртуализация на ниво сървърна услуга (например уеб сървър), а още по-добре контейнеризация, защото получавате възможност за много по-фино настройване на производителност и отказоустойчивост и прецизен контрол по отношение на сигурност. Повече по темата:

Виртуализация –

Контейнеризация –

Съвети за избор и експлоатация на дейта център

Увод

Целта на документа е да дефинира обща методологична и организационна рамка за избор на дейта център и последващото изграждане и експлоатация на информационна инфраструктура. Документът няма претенции за всеобхватност и отразява опита на автора в:

  • Изграждане и експлоатация на дейта център бизнес
  • Избор на дейта център за различни услуги в спектъра голям бизнес – доставчик на услуги – интернет и телеком оператор

Описани са цялостният процес за подготовка, избор, изпълнение и успешна експлоатация.

Контрол на качеството

Контролът на качеството е от ключово значение за IT операциите на организацията, както въобще и за цялостната ѝ дейност. Ето защо описвам в по-големи детайли методологията за осигуряване на качество.

Контрол на качеството на монтаж на оборудване
  • Принципи
    • Изготвяне на подробен работен проект
    • Детайлно разработен план график за монтаж, тестване и пуск в експлоатация
    • Детайлно описани дейности по инсталация и монтаж
    • След доставка оборудването се подлага на функционални тестове преди окончателен монтаж
    • Оборудването се инсталира съгласно утвърдената практика – инсталация от обучен екип, притежаващ всички необходими за дейността сертификати, при пълно спазване на определената от проектанта и доставчиците технология и в координация с персонала на организацията или трети лица, който осигурява методическа подкрепа и необходимите проводи за електрически и мрежови свързаности
    • Спазване на правилата за безопасност на труда и пожарна безопасност
    • Преди въвеждането на оборудването в редовна експлоатация се извършват необходимите огледи и изпитания за удостоверяване на съответствието им с проекта и с действащите правилници и нормативни документи третиращи дадения вид дейност
    • Изработва се подробна техническа документация на направените инсталации и към нея се прилагат всички протоколи от извършени измервания, тествания и сертифициране на системите, включително с описания и снимков материал
  • Методи
    • Изработването на тестови казуси при които се проследяват номиналните експлоатационни параметри и се предприемат действия за влизане в номинал
    • След инсталация оборудването се включва в система за наблюдение и управление
    • Оборудването се включва в система за наблюдение на производителност, и наличност на услугата на ниво система за наблюдение и управление през мрежовата свързаност
    • Непрекъснато следене параметрите на хардуера – температура, захранващо напрежение по компоненти, състояние на вентилатори
    • Непрекъснато следене SMART параметрите на твърдите дискове и SSD, за да се реагира своевременно при излизане на параметър извън допустимите граници
    • Тестови период, в който се проследяват номиналните експлоатационни параметри и се предприемат действия за влизане в номинал
    • Установява се процедура за взаимодействие  за известяване на събития между отговорните страни за поддръжка на организацията и оператора на дейта центъра
    • Установява се връзка между системата за наблюдение и управление на организацията и оператора на дейта център услугата
      • Система за сигнализация при проблем
      • Система за ескалация на проблем, съгласно параметрите на договореното ниво на обслужване (SLA)
Контрол на качеството на дейности по осигуряване на мрежова свързаност

Контролът на качеството на дейностите по осигуряване на мрежова свързаност се осъществява с прилагане на следните принципи и методи:

  • Принципи
    • Детайлно разработен план график за изграждане на свързаности, тестване и пуск в експлоатация
    • Наемане на услуги от надеждни телекомуникационни оператори,  с дългогодишен опит в експлоатацията на градски и мобилни мрежи
    • Използване на надеждно и отказоустойчиво оборудване от реномирани доставчици, разполагащи с отлична сервизна база
    • Пълна документация на направените свързаности, включително с описания и където е уместно – снимков материал
  • Методи
    • След провизиране на услуга, комуникационното трасе се включва в системата за наблюдение на производителност, качество и наличност на услугата
    • Непрекъснато следене на качествените параметри и ескалация при деградация на параметър извън договореното ниво на обслужване
    • Тестови период, в който се измерва качеството на изградените свързаности и се синхронизира взаимодействието между центровете за поддръжка на организацията и телекомуникационните оператори
    • Връзка между системата за наблюдение и управление на организацията и телекомуникационни оператори
      • Автоматизирана сигнализация при проблем
      • Автоматизирана ескалация на проблем, съгласно параметрите на договореното ниво на обслужване
Предварителна подготовка

Правилно подготвеното задание е предпоставка за получаване на добре обмислена и остойностена оферта от страна на дейта център оператора. Трябва да отговорите на следните въпроси на ниво организация:

  • Как изглежда, каква е архитектурата и какви са параметрите на цялостната информационна система – на ниво дейта център и (ако има) информационни системи на огранизацията извън дейта центъра 
  • Какви SLA ангажименти следва да гарантира тази инфраструктура (например SLA към клиентите на организацията, към вътрешни за организацията потребители), за да можете да определите своите изисквания към оператора на дейта центъра и телекомуникационните оператори (ако са различни)
  • Какви са възможностите на организацията да обслужва своя SLA – налични човешки ресурси и специализирани информационни системи
  • За препоръчване е да имате количествено изражение на SLA – време, дължимо/очаквано обезщетение. Можете да използвате този SLA Calculator, за да проиграете различни варианти
  • Направете цялостна технологична оценка
    • Размер на оборудването – дълбочината на сървърите е съществен параметър
    • Вентилационен поток – фронт към гръб или странично
    • Начин за монтаж на оборудването в шкафовете
      • Носещи шейни
      • Лавици
      • Кабелни водачи или прикрепващи скоби
    • Захранване – брой на захранванията на единица оборудване – необходимо е, за да се предвидят достатъчно на брой разклонители. Имайте предвид, че последващото добавяне на разклонители не винаги е удобна опция, а понякога не е възможно без сериозно пренареждане на оборудване, което предполага и прекъсване на услуги
    • Обща консумация в начален и максимален капацитет
    • Брой и вид на мрежова свързаност за всяко оборудване
    • Потенциална необходимост от изграждане на повече свързаности към разпределителни табла в дейта центъра
    • Логистика на оборудването
      • Начална – при инсталация – рампи, подходи, асансьори
      • Експлоатационна – оперативна доставка или съхранение на резервни части (дискове, сървъри, мрежово оборудване) 
      • Достъп до дейта центъра в работно/извън работно време.
    • Упълномощени лица и процедура за идентификация – на място и отдалечено (например телефон, мейл)
    • Имайте предвид, че ако получавате мрежови услуги от трети оператори на територията на дейтацентъра, е необходимо да отчитате правилно точния ангажимент, който дейта център оператора и телеком оператора имат към Вас. Не очаквайте да получите нещо повече или различно от това, което е описано в договора 
  • Направете оценка за цялостната цена на дейта център услугата. Определете TCO (Total Cost of Ownership), като отчитате следните компоненти
    • Цена на колокация на оборудване. Обикновено се отчита на 1RU (rack unit) или кратно на капацитет на шкаф
    • Цена за електрическа консумация – може да се смята по номинал на инсталираното оборудване, да се измерва с контролен електромер или да се подава като информация от захранващата система на дейта център оператора 
      • Имайте предвид, че в дългосрочен план цената на електрическата енергия се увеличава. От тази гледна точка е разумно да се заложи на последно поколение оборудване, поради по-голямата му енергийна ефективност 
    • Цена за допълнителни услуги тип “поддръжка на място” (“remote hands”) и какво конкретно се включва в нея
    • Размер и степен на отговорност на оператора на дейта центъра към инсталираното оборудване и предоставяните услуги
Критерии за избор

Изборът на дейта център и начинът, по който се извършва експлоатацията на оборудването, свързаностите и услугите в него са елемент от стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery). Това е постоянен процес, а не еднократно планирана и извършена работа. Добрата съвместната работа с дейта център оператора е от ключово значение за този процес.

За целите на този документ приемам, че технологичните и финансови параметри на нуждите на организацията са удовлетворени.  Нека разгледаме останалите критерии, които може да определят окончателното решение:

  • Наличие в дейтацентър оператора на капацитет да обслужи нуждите на организацията – например:
    • Персонал като количество и качество
    • Наличие на информационни системи, които реализират, не само необходимата за дейта център/телеком оператора функционалност, но могат да бъдат свързани със съответните системи на организацията
    • Съветваме да проучите дългосрочната финансова и организационна стабилност на дейта център оператора
  • Съвместими организационни култури и ниво на зрялост в дейта център оператора и Вашата организация
  • Потенциал за развитие в оператора, който да гарантира дългосрочното Ви взаимодействие
    • Технологичен потенциал
    • Бизнес потенциал
  • По възможност се насочвайте към оператори, които достатъчно дълго време експлоатират дадена инфраструктура и/или технологично решение.
    • Избягвайте да бъдете първи клиент в нов център или инфраструктура, освен ако SLA, под чиито рамки работите, не позволява поемането на подобен риск
  • Анализирайте SLA предложението. То следва да демонстрира:
    • Постижими за организацията на оператора параметри. Проверете ги. 
      • Потърсете мнение от други клиенти
      • Потърсете мнения по форуми и потребителски групи
    • Зрялост – детайлно разписани отговорности и процес а работа
    • Смислен процес на ескалация – достатъчо нива, но без формално размиване на процеса
      • Плюс е, ако има механизъм, да ексалирате до висш мениджмънт
      • Минус е, ако висшият мениджмънт е необходим на всяка стъпка в процеса на офериране, преговори, предоставяне на услуга, експлоатация
    • Достатъчно точки за недвусмислен контрол –
      • Конкретни количествени критерии за качество и наличност
      •  Възможност за независимо измерване на количествените параметри
      • Интерфейс за наблюдение в реално време на параметри, които са в контрол на оператора (например електрическа консумация)
  • Дейта център операторът следва да предостави ясна и изпълнима процедура по сигурността 
Планиране и изпълнение
  • След доставка, оборудването се проверява за комплектовка и електрическа работоспособност от екип на организацията
    • Имайте предвид, че дори при използване на ново (или дори вече работило във Вашата инфраструктура) оборудване, са възможни проблеми или неработещи компоненти
    • Планирайте с излишък от време
  • Оптимално е монтажът на оборудването в дейта центровете да се извършва от обучен персонал на дейта център оператора под Ваш методически контрол и съгласно предварително съгласувана инструкция за монтаж, маркировка на оборудване и свързващи кабели
  • Фиксирането на оборудването, захранващите и мрежови кабели, се извършва съгласно добрите практики и конкретните особености на използваните шкафове за оборудване, кабелни разпределителни системи и захранващи системи
  • Монтажът на оборудването следва да отговаря на изискванията за лесен достъп за профилактика и процедури за добавяне на нови модули – например памет и дискове. Изваждането на сървър за профилактика, сервиз или добавяне на модули следва да се извършва без необходимост от прекъсване работата на останалите сървъри, като подвеждането на захранващи и комуникационни кабели трябва да изключва или намалява до минимум риска от неволно прекъсване или влошаване на устойчивост на свързване
  • Използват се само фабрично произведени и тествани преди монтаж захранващи и комуникационни кабели
  • След физически монтаж се пристъпва към електрическо оживяване и проверка за правилно свързване към захранващите А и Б подсистеми. Идентифицират се предпазителите осблужващи конкретните сървъри и шкафове
  • Описва се местоположение, маркировка, комуникационни и захранващи кабели за всяко оборудване, както и местоположението на предпазителите на електроразпределителното табло и направените комуникационни кроскънекти
  • Добра практика е документацията да се подготвя в процеса на инсталация, отколкото да се разчита на спомени от трети лица
Успешна експлоатация

Минимално необходимо е:

  • Поддръжка на актуална документация
  • Регулярни контакти с дейта център оператора
  • Регулярни посещения (несвързани с проблеми) в дейта центъра
    • Необходими са, за да имате наблюдения върху развитието на оператора и да получите ранна и изпреварваща информация за потенциални организационни и/или финансови проблеми
  • Изграждане в организацията на Оперативен център, който осигурява тотален мониторинг и контрол на всички параметри свързани със:
    • SLA на дейта център оператора към организацията 
    • SLA на организацията към нейните вътрешни и външни клиенти
  • Връзка между тикетинг системата на организацията и съответния и аналог в Дейта център и телеком операторите
  • Поддържане на актуални процедури за действие в случай на отказ на оборудване, свързаности или дейта център. Тестове на оборудване и действия на персонал в случай на необходимост
За повече информация:
Съвети към IT мениджъра:
  • Изборът на дейта център и начинът, по който се извършва експлоатацията на оборудването, свързаностите и услугите в него са елемент от стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery). Това е постоянен процес, а не еднократно планирана и извършена работа. Добрата съвместната работа с дейта център оператора е от ключово значение за този процес
  • Доколкото смяната на дейта център е изключително тежко, времеемко и с множество скрити разходи упражнение, добрият избор е от бизнес критично значение

Решения за бекъп и архивиране

Принципи и технология

Системата за архивиране отговаря за надеждното съхраняване на архивни копия на работните данни и системи. Архивирането представлява не само процедура за запазване на архивни копия през определени интервали от време, но осигурява комплекс от мерки, които се предприемат, за да се осигури възможност за възстановяване при системен срив, хакерска атака, бедствия.

  • Пазят се:
    • Архивни копия на данни
    • Виртуализирани системи
    • Конфигурации на системи и услуги
  • По време на експлоатацията на системата се правят:
    • Периодични моментни снимки (snapshots) на системите заедно с работните данни
    • Моментни снимки преди конфигурационни промени
    • Периодични, дневни, седмични и месечни архивни копия
Възстановяване на операциите при срив

Организира се по следният начин:

  • Определяне причина за срив, за да се гарантира интегритета на системата, нейните функции и натрупани данни
  • Изключително важно е да се установи причината за настъпил срив (примерно, ако се използва за маскиране на евентуална хакерска атака). За постигане на целта се прави анализ на натрупаната системна лог информация
  • Работните системи се възстановяват от моментните снимки, за да се осигури бързо преминаване към нормален работен режим
  • Последващо се прави анализ за интегритет на данните, за да се гарантира, че няма изпуснати събития
  • При нужда се възстановяват копия от системните данни през системата за архивиране
Оптимални характеристики на системата за архивиране и бекъп
  • Бизнес клас решение дори на база отворен код
  • Бекъп пространство за съхранение на цялостни и инкрементални резервни копия на всички бази данни и системни компоненти
  • Автоматизирани резервни копия– предварително дефинирано разписание
  • Отворени формати – добра практика е възстановяването на данните да е възможно дори при разрушена инфраструктура – неработещ бекъп сървър
  • Поддръжка на всички разпространени операционни системи, най-малко на използваните в организацията
  • Поддръжка на бекъп върху дискове, ленти, автоматизирани библиотечни системи, клауд базиран сторидж
  • Компресия и дедупликация на данни
  • Криптиране при клиента (end to end encryption)
За повече информация:
Съвети към IT мениджъра:
  • Дефинирането на основни бекъп политики и вписването в стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery) е процес, който трябва да бъде подплатен с необходимите човешки ресурси и подкрепа от ръководството

BareOS Backup

Кратко описание

BareOS (Backup Archiving Recovery Open Sourced) e бекъп система за архивиране с отворен код за хетерогенни системи (работни станции, сървъри, различни операционни системи и приложения)

BareOS е вариант (fork) на Bacula поддържа всички нейни функции и възможности като се отличава с по-динамично развитие.

  • Поддържа всички основни бекъп функции. Работи с всички разпространени операционни системи и бази данни
  • BareOS поддържа Linux, UNIX, Windows и macOS архивиращи клиенти и редица професионални архивиращи устройства, включително лентови библиотеки
  • Има комерсиална версия и разширена поддръжка
  • BareOS позволява един сървър да архивира множество мрежови клиенти към лентова или дискова система за съхранение
  • Добре направена документация с множество примери
  • Инсталация и конфигурация са правят относително лесно и бързо
  • Необходимо е сериозно планиране и проектиране на бекъп система базирана на BareOS
  • Предлага ентърорайс клас криптиране от край до край. Шифроването при крайния клиент гарантира сигурността на данните при транзит, а криптирането на ниво бекъп сървър гарантира сигурността на архивираните данни
  • BareOS поддържа до 4096-битови ключове с криптография с публичен ключ, както и 256-битово AES криптиране
Подходящ за:
  • Изграждане на тотално решение за бекъп и архивиране за всякакви сървъри, клиенти и размери на организацията
Неподходящ за:
  • Индивидуално бекъп решение – един компютър или работно място
За повече информация:
Защо BareOS:
  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите
  • Предлага ентърпрайс клас криптиране от край до край. Шифроването при крайния клиент гарантира сигурността на данните при транзит, а криптирането на ниво бекъп сървър гарантира сигурността на архивираните данни
Недостатъци:
  • Няма много материали на български език
  • В безплатната версия на BareOS:
    • Няма вградена поддръжка (без необходимост от специализирани агенти) на виртуални машини, бази данни, контейнери, приложения
Оценка на необходимите ресурси при внедряване:
  • Инсталация и конфигурация са правят относително лесно и бързо, но дефинирането на бекъп политиката на организацията трябва да е предварително направено
Степен на завършеност на решението:
  • Завършено решение
Съвети към IT мениджъра:
  • BareOS позволява изграждане на напълно функционална система за бекъп и архивиране без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Дефинирането на основни бекъп политики и вписването в стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery) е процес, който трябва да бъде подплатен с необходимите човешки ресурси и подкрепа от ръководството

Bacula Backup

Кратко описание

Bacula е бекъп система за архивиране с отворен код за хетерогенни системи (работни станции, сървъри, различни операционни системи и приложения)

  • Поддържа всички основни бекъп функции. Работи с всички разпространени операционни системи и бази данни
  • Bacula поддържа Linux, UNIX, Windows и macOS архивиращи клиенти и редица професионални архивиращи устройства, включително лентови библиотеки.
  • Има комерсиална версия и разширена поддръжка
  • Bacula позволява един сървър да архивира множество мрежови клиенти към лентова или дискова система за съхранение
  • Добре направена документация с множество примери
  • Инсталация и конфигурация са правят относително лесно и бързо
  • Необходимо е сериозно планиране и проектиране на бекъп система базирана на Бакула
  • Предлага ентърорайс клас криптиране от край до край. Шифроването при крайния клиент гарантира сигурността на данните при транзит, а криптирането на ниво бекъп сървър гарантира сигурността на архивираните данни
  • Бакула поддържа до 4096-битови ключове с криптография с публичен ключ, както и 256-битово AES криптиране.
Подходящ за:
  • Изграждане на тотално решение за бекъп и архивиране за всякакви сървъри, клиенти и размери на организацията
Неподходящ за:
  • Индивидуално бекъп решение – един компютър или работно място
За повече информация:
Защо Bacula:
  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите
  • Предлага ентърпрайс клас криптиране от край до край. Шифроването при крайния клиент гарантира сигурността на данните при транзит, а криптирането на ниво бекъп сървър гарантира сигурността на архивираните данни
Недостатъци:
  • Няма много материали на български език
  • В безплатната версия на Бакула:
    • Относително бавно развитие, особено забележимо при уиндоус клиентите
    • Няма вградена поддръжка (без необходимост от специализирани агенти) на виртуални машини, бази данни, контейнери, приложения
Оценка на необходимите ресурси при внедряване:
  • Инсталация и конфигурация са правят относително лесно и бързо, но дефинирането на бекъп политиката на организацията трябва да е предварително направено
Степен на завършеност на решението:
  • Завършено решение
Съвети към IT мениджъра:
  • Bacula позволява изграждане на напълно функционална система за бекъп и архивиране без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Дефинирането на основни бекъп политики и вписването в стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery) е процес, който трябва да бъде подплатен с необходимите човешки ресурси и подкрепа от ръководството

Amanda Backup

Кратко описание

AMANDA (Advanced Maryland Automatic Network Disk Archiver) е една от най-пълните и дългосрочно развивани бекъп системи.

  • Поддържа всички основни бекъп функции. Работи с всички разпространени операционни системи и бази данни
  • Има комерсиална версия и разширена поддръжка
  • Amanda позволява един сървър да архивира множество мрежови клиенти към лентова или дискова система за съхранение
  • Аманда е добре документирана
  • Инсталация и конфигурация са правят относително лесно и бързо
  • Amanda предоставя уникална възможност за едновременно записване на архиви на лента и диск. Така данните могат да бъдат съхранявани на диск за бързо възстановяване и на лента за особено дългосрочно съхранение
  • Amanda не използва собствени драйвери за устройства, като следствие – всяко устройство, поддържано от операционна система, работи добре с Amanda.
  • Проектът с отворен код Amanda се поддържа от голяма и продуктивна общност
  • Предлага ентърпрайс клас криптиране от край до край. Шифроването при крайния клиент гарантира сигурността на данните при транзит, а криптирането на ниво бекъп сървър гарантира сигурността на архивираните данни
  • Amanda поддържа до 4096-битови ключове с криптография с публичен ключ, както и 256-битово AES криптиране.
Подходящ за:
  • Изграждане на тотално решение за бекъп и архивиране за всякакви сървъри, клиенти и размери на организацията
Неподходящ за:
  • Индивидуално бекъп решение – един компютър или работно място

За повече информация:

Защо Amanda:

  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите
  • Предлага ентърпрайс клас криптиране от край до край. Шифроването при крайния клиент гарантира сигурността на данните при транзит, а криптирането на ниво бекъп сървър гарантира сигурността на архивираните данни
  • Amanda поддържа до 4096-битови ключове с криптография с публичен ключ, както и 256-битово AES криптиране
  • Аманда архивите могат да се възстановят и ръчно, тъй като са копие на файловите системи на хостовете, които се архивират с tar. Т.е. Amanda архив е възстановим, дори без инсталация на Аманда сървър

Недостатъци:

  • Няма много материали на български език
  • Безплатната версия няма уеб базирана конзола за управление
  • В безплатната версия на Аманда:
    • Относително бавно развитие, особено забележимо при уиндоус клиентите
    • Няма вградена поддръжка (без необходимост от специализирани агенти) на виртуални машини, бази данни, контейнери, приложения

Оценка на необходимите ресурси при внедряване:

  • Инсталация и конфигурация са правят относително лесно и бързо, но дефинирането на бекъп политиката на организацията трябва да е предварително направено
  • Поддръжката на Аманда бекъп решение предполага квалифицирани систрмни администратори
Степен на завършеност на решението:

  • Завършено решение
Съвети към IT мениджъра:

  • Amanda позволява изграждане на напълно функционална система за бекъп и архивиране без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Дефинирането на основни бекъп политики и вписването в стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery) е процес, който трябва да бъде подплатен с необходимите човешки ресурси и подкрепа от ръководството

Security Onion Hybrid Hunter

Кратко описание

Security Onion Hybrid Hunter е следващата версия на Security Onion и текущо е в алфа тест. Отделям внимание на този незавършен продукт, защото като замисъл тази версия трябва да отстрани основните недостатъци на SO и може би си струва да се изчака и евентуално използва SO HH за реализация на мащабни open source SIEM системи в големи организации. 

За повече информация:
Защо Security Onion Hybrid Hunter:
  • SO-HH вероятно ще реши проблемите на SO като добави интегрирани възможности за корелация, анализ и управление на действия
  • В допълнение – модерната, базирана на контейнери архитектура на HH, би могла да предопредели дълъг живот и улеснена поддръжка на системата
Недостатъци:
  • На този етап е рано да се прецени
Оценка на необходимите ресурси при внедряване:
  • Тъй като SO HH представлява appliance – инсталацията и базовата конфигурация на сървър и агенти е лесна и бърза
  • Началната конфигурация – стартиране на базов мониторинг на сигурността, отнема 4-8 часа
  • Разширени конфигурации – рано е за оценка
  • Дори за средна по мащаб на използваните информационни технологии организация, е необходимо да се осигури хардуер, способен да осигури необходимата производителност
  • Добре се виртуализира и може да спестите използването на физически сървър. Все пак – отделете необходимия ресурс. 
Степен на завършеност на решението:
  • Ранна алфа версия
  • Множество проблеми
Съвети към IT мениджъра:
  • Изчакайте. SO HH може да е добра основа за изграждане на SIEM решение за Вашата организация. 
  • Никога не считайте, че използването на SIEM система и каквато и да е технология за защита е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

Security Onion

Кратко описание

Security Onion е SIEM (Security Information and Event Management) система с отворен код и представлява Linux дистрибуция за откриване на прониквания, наблюдение на сигурността на организацията и управление на логове. Основни функции:

  • Събиране на информация от мрежата в реално време (full realtime packet capture)
  • Мрежови и хост-базирани системи за откриване на проникване (NIDS и HIDS)
  • Мощни инструменти за анализ

Включва:

  • ELK Stack – Elasticsearch, Logstash, Kibana – събиране, съхранение, обработка и визуализация на информация
  • Snort – използва се като система за откриване на проникване базирана на правила (Rule driven IDS  – Intrusion Detection System)
  • Suricata – използва се като система за откриване на проникване базирана на правила (Rule driven IDS  – Intrusion Detection System)
  • Bro – използва се като система за откриване на проникване базирана на анализ (Analysis driven IDS  – Intrusion Detection System)
  • OSSEC – хост базиранa системи за откриване на проникване (HIDS)
  • Wazuh – използва се като система за откриване на проникване в сървъри (Host based IDS  – Intrusion Detection System)
  • Sguil – Система за анализ
  • Squert – Уеб интерфейс към Squil
  • И много други инструменти за сигурност

Security Onion представлява колекция от инструменти, предназначени да подпомогнат процеса на поддръжка на информационната сигурност – откриването, управление на последици и предотвратяване на прониквания. Представлява security appliance – специализирана Линукс дистрибуция, работеща върху отделен физически или виртуализиран сървър. Поддържа агенти, които могат отдалечено да събират и изпращат информация към разпределената система за обработка и визуализация. SO предоставя на системни и мрежови администратори, DevSecOps и аналитици в областта необходимите средства за събиране, обработване, анализ, представяне и визуализация на информация. 

Подходящ за:
  • Поставяне основи на SOC (Security Operations Center) на организацията
  • Управление информационната сигурност на голяма организация – SO позволява изграждането на разпределена система от колектори, процесори на информация и сторидж системи
Неподходящ за:
  • Решаване на проблемите с информационната сигурност в организации, които нямат съответните човешки ресурси
За повече информация:
Защо Security Onion:
  • Зрял проект с дългогодишно развитие и широка база от разработчици на много от неговите компоненти
  • Предлага съществена функционалност в безплатна версия
  • За разлика от конкурентни продукти (например AlenVault OSSIM) има вграден и много добър механизъм за събиране, обработка и визуализация на логове (ELK stack)
  • Има комерсиална поддръжка
  • Безплатната версия има относително добра документация, както и някаква поддръжка от общността на потребителите
Недостатъци:
  • Макар положените усилия за сглобяване и интегриране на различните средства, дистрибуцията е доста насипна и еклектична комбинация от отделни продукти, които в повечето случаи се конфигурират и управляват през множество разположени във файловата система конфигурационни файлове без единен интерфейс
  • Макар да решава много задачи,  SO не позволява изграждането на тотално, цялостно и автоматизирано решение за информационна сигурност
  • Липсват възможности за организиране на йейрархии и управление на действия при секюрити събития
  • Липсва единен механизъм за изпращане на алерти
  • Редки ъпдейти
Оценка на необходимите ресурси при внедряване:
  • Тъй като SO представлява appliance – инсталацията и базовата конфигурация на сървър и агенти е лесна и бърза
  • Началната конфигурация – стартиране на базов мониторинг на сигурността, отнема 2-4 часа
  • Разширените конфигурации са в зависимост от мащаба на организацията и може да са необходими много дни за постигане на удовлетворяващи резултати
  • Дори за средна по мащаб на използваните информационни технологии организация, е необходимо да се осигури хардуер, способен да осигури необходимата производителност
  • Добре се виртуализира и може да спестите използването на физически сървър. Все пак – отделете необходимия ресурс. 
Степен на завършеност на решението:
  • Насипно решение.
  • Някои компоненти работят добре и веднага, други изизкват много време за конфигурация. 
Съвети към IT мениджъра:
  • Security Onion е добра начална стъпка за осигуряване на информационна сигурност в голяма организация и може да се използва за обучение на персонал и развитие на вътрешна за организацията експертиза
  • Доколкото информационната сигурност е процес – развитието на SO в рамките на организацията е също непрекъсната и регулярна задача и следва да се подплати с необходимите хора, технически средства, време и обучение
  • Необходима е специализирана в областа на информационната сигурност експертиза
  • Ако нямате добри системни и мрежови администратори, R&D персонал и достатъчно време да поддържате насипно решение от различни компоненти с отворен код – по-скоро рано, отколкото късно – ще се наложи да търсите и мигрирате към комерсиално решение ИЛИ да аутсорснете информационната си сигурност към външна организация
  • Никога не считайте, че използването на SIEM система и каквато и да е технология за защита е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

Операни предлага инсталация, интеграция със съществуващи компоненти, експлоатация и поддръжка на комплексни SIEM решения в инфраструктура на клиента, публични и частни облаци или върху специализиран Operani Operations Cloud

AlienVault OSSIM

Кратко описание

AlienVault OSSIM (Open Source Security Information Management) е SIEM (Security Information and Event Management) система с отворен код, интегрираща набор от инструменти, предназначени да подпомогнат процеса на поддръжка на информационната сигурност – откриването, управление на последици и предотвратяване на прониквания. Представлява security appliance – специализирана Линукс дистрибуция, работеща върху отделен физически или виртуализиран сървър. Понастоящем, AlienVault OSSIM е част от AT&T Cybersecurity. 

OSSIM не само събира различни средства с отворен код, но ги интегрира в общ интерфейс за управление, обмен на данни, възможност за корелиране на събития и управление на инциденти свързани със сигурността. Така OSSIM предоставя на системни и мрежови администратори, DevSecOps и аналитици в областта необходимите средства за събиране, обработване, анализ, представяне и визуализация на информация. 

AlienVault OSSIM има автоматизирани механизми за събиране на инвентарна (сканиране на мрежи, детекция на операционни системи, работещи услуги) и лог информация. Сканира за уязвимости, управлява събития, техния контекст и взаимна корелация. Генерира аларми, предписания и ескалира действия в рамките на SOC (Security Operations Center) на организацията. 

Чрез активиране на сървър и агенти в различните офиси/локации на организацията, може да се обхване цялостната и дейност в единна система. 

Компоненти:

  • PRADS – използва се за идентифициране на хостове и услуги чрез пасивно наблюдение на мрежовия трафик
  • Suricata – използва се като система за откриване на проникване (IDS  – Intrusion Detection System)
  • Tcptrack – използва се за анализ на данни от TCP сесии, да предоставя полезна информация за корелиращите механизми
  • Munin – използва се за трафичен анализ и наблюдение на услуги
  • NFSen / NFDump – използва се за събиране и анализ на NetFlow 
  • FProbe – използва се за генериране на NetFlow от уловен трафик
  • Nagios – използва се за наблюдение на хостове и услуги
  • OpenVas – използва се за оценка на уязвимостта на наблюдавани хостове и услуги
  • В допълнение OSSIM включва разработени от AlienVault инструменти, като най-важният е генерален механизъм за корелация с логическа поддръжка на директиви и обработка на лог информация със специализирани процесори
Подходящ за:
  • Поставяне основи на SOC (Security Operations Center) на организацията
Неподходящ за:
  • Решаване на проблемите с информационната сигурност в организации, които нямат съответните човешки ресурси. 
  • Управление информационната сигурност на голяма организация – същественото ограничение е, че OSSIM обработва информацията само на един сървър
За повече информация:
Защо OSSIM:
  • Зрял проект с дългогодишно развитие и широка база от разработчици 
  • Предлага доста от необходимата функционалност в безплатната версия
  • Има комерсиална версия с повече възможности и разширена поддръжка
  • Безплатната версия има много добра документация, както и достатъчно надеждна поддръжка от общността на потребителите
  • Много добра документация, включително обучаващи клипове и редовни уебинари по различни аспекти на информационната сигурност
Недостатъци:
  • OSSIM е opensource вариант на комерсиален и скъп продукт, има мек натиск за преминаване към платената версия
  • Макар да решава много задачи, OSSIM не позволява изграждането на тотално, цялостно и автоматизирано решение за информационна сигурност
  • Съществуват дребни (но отнемащи време на администраторите на OSSIM) проблеми, които не се отстраняват с години. Все пак следва да се отчита, че големите проблеми се отстраняват достатъчно бързо
  • Редовните ъпдейти на OSSIM – няколко пъти седмично, отнемат доста време и понякога се налага отстраняване на проблеми предизвикани от самия ъпдейт
Оценка на необходимите ресурси при внедряване:
  • Тъй като OSSIM представлява appliance – инсталацията и базовата конфигурация на сървър и агенти е лесна и бърза
  • Началната конфигурация – стартиране на базов мониторинг на сигурността, отнема 2-4 часа
  • Разширените конфигурации, включително дефинирането на необходимите за спецификата на организацията корелационни правила, отнема време в зависимост от мащаба на организацията и може да отнеме дни
  • Дори за средна по мащаб на използваните информационни технологии организация, е необходимо да се осигури хардуер, способен да осигури необходимата производителност
  • Добре се виртуализира и може да спестите използването на физически сървър. Все пак – отделете необходимия ресурс. 
Степен на завършеност на решението:
  • Завършено в голяма степен решение, но в безплатната версия липсат необходими компоненти – например сървър за запазване и обработка на историческа лог информация
  • Необходимо е дефиниране нужните на организацията корелационни правила
Съвети към IT мениджъра:
  • Струва си – AlienVault OSSIM е добра начална стъпка за осигуряване на информационна сигурност и може да се използва за обучение на персонал и развитие на вътрешна за организацията експертиза
  • Доколкото информационната сигурност е процес – развитието на OSSIM в рамките на организацията е също непрекъсната и регулярна задача и следва да се подплати с необходимите хора, технически средства, време и обучение
  • Необходима е специализирана в областа на информационната сигурност експертиза
  • Ако нямате R&D персонал и достатъчно време да създавате корелатори на събития и отчети за конкретните си нужди на – по-скоро рано, отколкото късно – ще се наложи ИЛИ да преминете към комерсиалната версия ИЛИ да аутсорснете информационната си сигурност към външна организация
  • Никога не считайте, че използването на SIEM система и каквато и да е технология за защита е достатъчна за сигурността на организацията. Сигурността е процес, а не само технология.  

Операни предлага инсталация, интеграция със съществуващи компоненти, експлоатация и поддръжка на комплексни SIEM решения в инфраструктура на клиента, публични и частни облаци или върху специализиран Operani Operations Cloud

OpenNebula

Кратко описание

OpenNebula е мощно и гъвкаво решение с отворен код за изграждане, оркестрация и експлоатация на частни и хибридни виртуализационни и клауд решения. Позволява работа в режим инфраструктура като услуга (IaaS).

Използват се KVM, LXD и Vmware хипервайзори. Поддържа инфраструктура разположена в един или множество дейта центрове. Позволява виртуализация на ниво центрове за данни и/или облачна инфраструктура.

OpenNebula е софтуер с отворен код и Apache лиценз.

OpenNebula оркестрира сторидж, мрежа, виртуализация, мониторинг и сигурност. Разполага с инструментариум, включващ интеграция, управление, мащабируемост, сигурност и акаунтинг на предоставяните услуги. ОпънНебюла поддържа и съчетава множество йерархии от потребители и услуги (multitenancy), като осигурява съвместната работа, управление на споделени ресурси, отказоустойчивост (High Availability), възстановяване от срив (Disaster Recovery).

OpenNebula може да се използва за управление на виртуални дейта центрове, федерация на дейта центрове и хибридни решения. Заради поддържаните отворени и частни стандарти, OpenNebula позволява изграждане на хибридни решения в Amazon EC2, OpenStack, GCP.

Подходящ за:
  • Оркестрация на виртуализация на ниво голям бизнес, клауд провайдър и телеком провайдър 
Неподходящ за:
  • Решения за малък бизнес
  • Оркестрация на контейнери (изключение LXD контейнери)
За повече информация:
Защо OpenNebula:
  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите
  • Интегрирано решение за High Availability / Disaster Recovery
  • API за връзка с трети продукти
Недостатъци:
  • Липса на интерирано бекъп решение
  • Липса на интегрирано управление на сторидж 
  • Поддържа само LXD контейнер технология, няма директна поддръжка на Docker и Kubernetes. Т.е. те могат да се инсталират във виртуални машини под OpenNebula управление
  • Макар да има средства за визуализация на основни метрики на OpenNebula клъстера и поддържаните виртуални машини, контейнери и сторидж има какво да се желае в това отношение и е необходимо да се интегрира с продукти като Zabbix / GrayLog / Grafana, за да има функционални и богати средства за мониторинг на състоянието на клъстера и услугите
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Използване
    • Време за базово усвояване: 12-24 часа.
    • Необходимост от оперативна поддръжка: ниска до средна (под 6 часа месечно) за системи до 5 физически сървъра и 50 виртуални машини
  • Инсталация на OpenNebula – доста насипна, особено при клъстеризиране на системата за управление 
Степен на завършеност / Необходимост от развитие:

  • Комплексно решение с множество компоненти, които следва да се настроят и интегрират за съвместна работа
Съвети към IT мениджъра:
  • Подходящо е за решения в широк спектър – от няколко до хиляди сървъри, разположени в един или множество дейта центрове
  • OpenNebula е особено подходяща при изпълнение на някой от следните сценарии или произволна комбинация от тях:
    • Мащабни решения с поддръжка на множество дейта центрове
    • Изграждане и използване на хибридни клауд (hybrid cloud) решения – комбинация от частна инфраструктура на организацията и интерфейс за оркестриране на виртуализация върху публични клауд решения (например Amazon EC2)
    • Интеграция (например поради причина оптимизация на разходи) в единна система на различни хипервайзор технологии от бизнес клас (например VmWare) и Open Source  (KVM или Xen) 
  • Поради комплексния характер на OpenNebula и сценариите за използването ѝ, кривата на обучение е доста разтеглена и е необходимо наличие на администратори с много опит
  • Необходимо е да се разработят и/или интегрират допълнителни компоненти, за да се разполага с напълно развита OpenNebula система (Backup, Storage, Containers)
  • Използването на хипер конвергирана архитектура (сторидж система и виртуални машини споделят едни и същи физически сървъри) предполага добро планиране, изпълнение и непрекъснато наблюдение на пърформанс параметрите на системата

LibreNMS

Кратко описание

LibreNMS (ЛибреНМС) е SNMP система за мрежов мониторинг 

Форк е на известният софтуер за мрежово наблюдение Observium.

Доколкото работи по SNMP, може да се използва за наблюдение на всякакъв тип SNMP устройства, включително:

  • Сървъри, сторидж системи, HVAC, UPS и други. 
Характеристики:
  • Auto discovery – доста добре се справя включително със сложни топологии на мрежата. Отчита, както рутинг информация, така също и състоянието на интерфейсите. 
  • Alerting
  • Multiple environment sensors support
  • Multiple protocols data collection (STP, OSPF, BGP etc)
  • VLAN, ARP and FDB table collection
  • Customizable Dashboards
  • Device Backup integration (Oxidized, RANCID)
  • Distributed Polling
  • Multiple Authentication Methods (MySQL, LDAP, Active Directory, HTTP)
  • NetFlow, sFlow, IPFIX (NfSen)
  • Service monitoring (Nagios Plugins)
  • Syslog (Integrated, Graylog)
  • Traffic Billing (Quota, 95th Percentile)
  • Two Factor Authentication
  • API
  • Auto Updating
Интеграции
Подходящ за:
  • Цялостни решения за мониторинг и управление на мрежи. 
  • Автоматично откриване и визуализация на мрежови топологии
  • Организация поддръжка на комплексни мрежи
  • Трафичен анализ
  • Трафична статистика и подготовка на сметки и билинг
Неподходящ за:
  • Управление на цялостен мониторинг, включващ освен мрежи, базови (например web, database, load balancer), комплексни услуги и софтуерни компоненти 
За повече информация:
Защо LibreNMS:
  • Напълно open source решение без твърди или меки стимули за купуване на допълнителни компоненти и възможности. 
  • Поддържа щирок набор SNMP устройства
  • Много добър за проактивен мониторинг, наблюдение състояние на интерфейси, трафик, загуби на пакети, jitter
  • Може да се впише в корпоративна среда (LDAP/AD) 
  • При интеграция с Netflow и Smokeping може да се правят добри анализи на трафик и свързаности, за да се следи спазване на SLA и контролират оперативни разходи 
Недостатъци:
  • Съществените настройки се правят през съответни конфигурационни файлове, което затруднява поддръжката на продукта, особено ако е на много нива и компетентности 
  • Активираната по подразбиране опция за автоматично обновяване на LibreNMS, понякога води до проблеми, особено при големи промени в структурата на базата данни при преход между мейжър версии. В тази връзка е препоръчително автоматичните ъпдейти да се забранят, ако LibreNMS се използва в продукционна система
Оценка на необходимите ресурси при внедряване:
  • Инсталация при използване на базови настройки за малка до средна инфраструктура – относително лесна
  • Необходимите ресурси са в линейна зависимост от големината и комплексността на наблюдаваните системи, мрежи и услуги
  • Добре се вписва в налични среди за виртуализация
  • Относително добра документация
Степен на завършеност на решението:
  • LibreNMS прави перфектно това, за което е създаден – нито повече, нито по-малко. При комплексна инфраструктура и необходимост от наблюдение не само на устройства и мрежи, но на услуги и софтуерни компоненти – необходимо е да се добавят допълнителни решения – като например Zabbix, което може да увеличи натоварването на екипа и може да се обмисли дали да не се използва само Забикс като по-универсално решение 
Съвети към IT мениджъра:
  • Архитектурата на LibreNMS позволява да работи практически във всякакъв мащаб – от събиране на информация от няколко мрежови устройства, до големи мрежи тип “сървис провайдър”
  • Позволява изграждане на напълно функционална система без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Kривата на обучение е приемлива, дори администратори с малко опит бързо усвояват необходимите умения, за да го използват на входно ниво
  • При наблюдение на комплексни системи е необходимо добро планиране и провизиране на необходимите ресурси – процесорни ядра и памет.
    • Особено в случай, когато се наблюдават множество системи с голям брой наблюдавани параметри и се запазват данни за големи периоди от време – необходимо е да се осигури достатъчно дисково пространство, както и проследяване на консумацията му
    • Следва да се отчита, че (ако) събирането на netflow статистика генерира огромни логове

Операни предлага инсталация, интеграция със съществуващи компоненти, експлоатация и поддръжка на комплексни LibreNMS решения в инфраструктура на клиента, публични и частни облаци или върху специализиран Operani Operations Cloud

Zabbix

Кратко описание

Забикс е система за мониторинг и управление на IT инфраструктури – 

  • Мрежи
  • Хардуер
    • Сървъри, Сторидж системи, HVAC системи, Захранващи системи (UPS) 
  • Софтуер – бази данни, уеб сървъри, месидж брокери…
  • Цялостни услуги – с възможност за описание на взаимозависимости между отделни компоненти и услуги, както и проследяване изпълнението на споразумения за ниво на обслужване (Service Level Agreement). 

Подробно за всички поддържани технологии и интеграции – Zabbix Integrations

Подходящ за:
  • Цялостни решения за мониторинг и управление. 
  • Наблюдение на IT инфраструктура и услуги. Поддръжка с йерархични нива. Дашборди. 
  • Контролиране спазване на SLA (Service Level Agreement) от доставчици на услуги и към клиенти
Неподходящ за:
  • Автоматично създаване на топологична схема (карта) на мрежови връзки. Ръчно е възможно да се визуализират всевъзможни йерархии, но ако топологичната схема е необходимост, препоръчваме добавяне на решение като LibreNMS
За повече информация:
Защо Zabbix:
  • Напълно open source решение без твърди или меки стимули за купуване на допълнителни компоненти и възможности. 
  • Поддържа практически всички съществуващи IT инфраструктурни компоненти
    • Подробно за всички поддържани технологии и интеграции – Zabbix Integrations
  • Много добър за проактивен мониторинг на сървъри, системи, цели инфраструктури и услуги
  • Може да се впише в корпоративна среда (LDAP/AD) 
  • Поддръжка на организационни йерархии (multitenancy)
  • Поддръжка на потребители и групи
  • Допълнително REST API
  • Вградена архитектура за отказоустойчивост (клъстер от сървъри)
Недостатъци:
  • Няма автоматично изобразяване на мрежи и визуализиране на мрежовата топология
  • Изключително комплексен продукт, поради това изисква сериозна експертиза при експлоатация
  • Лоша поддръжка на LDAP и Active Directory
Оценка на необходимите ресурси при внедряване:
  • Инсталация при използване на базови настройки за малка до средна инфраструктура – относително лесна
  • Има вградена поддръжка на разпределена инфраструктура чрез локални прокси сървъри
    • Необходимите ресурси са в линейна зависимост от големината и комплексността на наблюдаваните системи, мрежи и услуги
  • Добре се вписва в налични среди за виртуализация
  • Добра документация
Степен на завършеност на решението:
  • Zabbix е завършено тотално решение за наблюдение на IT инфраструктура
  • Все пак следва да се отчита, че интеграциите с комплексни решения и инфраструктурни компоненти може да предполага писане на код и/или интеграционни скриптове
Съвети към IT мениджъра:
  • Архитектурата му позволява да работи практически във всякакъв мащаб – от събиране на информация от няколко хоста до големи комплексни системи, които генерират огромен брой съобщения и трафик
  • Позволява изграждане на напълно функционална система без инвестиции в лицензи, но (както всяка подобна, включително комерсиална, система) не е решение, което работи “out of the box”. Необходимо е добро предварително планиране, технологично време и достатъчен човешки ресурс
  • Kривата на обучение е приемлива, дори администратори с малко опит бързо усвояват необходимите умения, за да го използват на входно ниво
  • При наблюдение на комплексни системи е необходимо добро планиране и провизиране на необходимите ресурси – процесорни ядра и памет.
    • Особено в случай, когато се наблюдават множество системи с голям брой наблюдавани параметри и се запазват данни за големи периоди от време – необходимо е да се осигури достатъчно дисково пространство.  

Операни предлага инсталация, интеграция със съществуващи компоненти, експлоатация и поддръжка на комплексни Забикс решения в инфраструктура на клиента, публични и частни облаци или върху специализиран Operani Operations Cloud

Rancher – Enterprise Kubernetes Management

Кратко описание

Rancher (Ранчър) е уеб базирана платформа за оркестрация на Kubernetes (Кубернетес) клъстери с отворен код.

Предлага пълен набор от средства за организации, които изграждат контейнеризирани решения. Управлява оперативните и предизвикателствата пред сигурността при работа с множество Kubernetes клъстери, като предоставя на DevOps инженерите интегрирани инструменти за управление на натоварване и реализация на HA/DR инфраструктура. Ранчър позволява изграждане на частни, публични и хибридни контейнер инфраструктури. Rancher разполага със средства и добре се интегрира в CI/CD процесите на организацията. 

Подходящ за:
  • Оркестрация на контейнери на ниво малък, среден и голям бизнес
  • На ниво малък и среден бизнес има всички характеристики на тотално решение
Неподходящ за:
  • Излишно комплексен за малки и/или индивидуални решения
За повече информация:
Защо Rancher:
  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите
  • Макар безплатно решение, поддържа функционалности, които се реализират в индустриален стандарт като OpenShift
  • Работи с всички разпространени операционни системи без специфични ограничения в тази област
  • Добре се вписва в корпоративна среда (LDAP/AD) и в политиката за сигурност на компанията
  • Интегрирано решение за High Availability / Disaster Recovery
  • Библиотека с предварително дефинирани приложения, включително Helm
  • Интегрирано управление на сторидж – практически не се налага да се управлява отделно решение за сторидж
  • API за връзка с трети продукти
  • Цялостно решение (базирано на Grafana и Prometheus) за наблюдение на метрики на клъстера и компонените му
  • Няма натиск, както е, например при OpenShift, да се използват специфични дистрибуции и платени технологии с цел постигане на по-добра надеждност и производителност
  • Няма значителен риск при необходимост да се премине към алтернативно и платено решение, доколкото Ранчър надстроява, но не променя кардинално kubernetes
Недостатъци:
  • Няма известността и реномето на OpenShift. Това е причина да се приема с известно недоверие от софтуерните архитекти и бизнес потребители, особено в областта на развитието на ентърпрайс приложения
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Използване
    • Време за базово усвояване: 16-32 часа (включва docker, kubernetes, basic networking, basic security, basic CI/CD, basic HA/DR)
    • Необходимост от оперативна поддръжка –
      • Средна към висока, в зависимост от комплексността на приложенията и броя на клъстерите
      • Предполага специализиран персонал и по-голям екип, ако се работи за 7×24 бизнес критични решения
  • Инсталация на клъстер върху виртуални машини или отделен хардуер – отнема няколко часа 
Степен на завършеност / Необходимост от развитие:

  • Напълно завършено решение с всички необходими основни компоненти
  • Следва да се отчита, че наличието на компонент, например система за бекъп, не значи, че наличната система покрива всички възможни случаи
Съвети към IT мениджъра:
  • Rancher e тотално решение за изграждане на контейнерна инфраструктура. Може успешно да се използва вместо комерсиални решения като OpenShift
  • Kривата на обучение е приемлива, дори администратори с малко опит бързо усвояват оптималните умения, за да използват Rancher, но при всички случаи са необходими базови познания в областта на kubernetes –
    • Security, Networking, HA/DR, CI/CD и в частност YAML
  • Разполага с всички необходими компоненти (контейнери, мрежи, High Availability, Disaster Recovery, Backup, Storage), за бързо изграждане на необходимата инфраструктура
  • Може да се използва в хиперконвергирани архитектури (сторидж система, виртуални машини и контейнери споделят едни и същи физически сървъри), но системата следва да се проектира правилно и да се организира добро наблюдение на пърформанс параметрите на компонентите ѝ
  • Частните виртуализирани и контейнеризирани инфраструктури и приложения поставят допълнителни изисквания към управлението на системите.
    • Ако имате опит от използване на публични клауд услуги (AWS, Azure, GCP), следва да отчитате, че макар ценово по-изгодни (разбира се има изключения), частните инфрастрктури предполагат много повече и по-квалифицирани човешки ресурси 
    • Serverless парадигмата е смислена само при реализация в публична инфраструктура

ProxMox

Кратко описание – ProxMox

ProxMox е система за оркестрация на виртуализация базирана на отворен и свободен код. Накратко:

  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите

Позволява изграждане на бизнес клас системи за управление на виртуални машини и контейнери (KVM Virtual Machines, LXC containers) и сторидж (ZFS, Ceph) върху решение с отворен код без заключване към доставчик. Това включва не само самия ProxMox, но и необходими допълнителни компоненти, например за управление на сторидж (ZFS, Ceph).

В категорията управление на виртуални машини, ProxMox е може би най-завършеният (като набор от минимално необходими функционалности) продукт. 

При ProxMox няма опити потребителите да бъдат „меко“ или „директно“ стимулирани, за да преминат към по-пълната, по-завършена, по-работеща комерсиална версия – както е подхода при Citrix Xen Server.

Подходящ за:
  • Оркестрация на виртуализация на ниво малък, среден и голям бизнес
  • На ниво малък и среден бизнес има всички характеристики на тотално решение
Неподходящ за:
  • Доставчици на виртуализационни услуги (Virtualization Service Providers)
  • Оркестрация на контейнери (изключение LXC контейнери)
За повече информация:
Защо ProxMox:
  • Макар безплатно решение, поддържа функционалности, които се реализират в индустриален стандарт като VmWare.
  • Многократно надхвърля по възможности безплатната версия на Xen Server
  • По-добре интегрирано решение спрямо Open Nebula и Open Stack и за разлика от тях огромна част от необходимата функционалност присъства в базовия продукт и е налице веднага след инсталация
  • Подходящо е за решения в спектъра – 1 до 32 сървъра
  • Добре се вписва в корпоративна среда (LDAP/AD) и в политиката за сигурност на компанията
  • Интегрирано решение за High Availability / Disaster Recovery
  • Интерирано бекъп решение (само базови функционалности, ниво snapshot на операционна система)
  • Интегрирано управление на сторидж – практически не се налага да се управлява отделно решение за сторидж.
    • Локален (LVM/ZFS)
    • Разпределен (Software Defined Storage) – Ceph
  • API за връзка с трети продукти
  • Функционален безплатен Андроид клиент за наблюдение и управление + комерсиална версия с разширени възможности. 
Недостатъци:
  • Липсва мащаба и богатството от възможности за развитие на продукти като OpenStack и Open Nebula
  • Поддържа само LXC контейнер технология, няма директна поддръжка на Docker и Kubernetes. Т.е. те могат да се инсталират във виртуални машини под ProxMox управление. 
  • Макар да има средства за визуализация на основни метрики на ProxMox клъстера и поддържаните виртуални машини, контейнери и сторидж има какво да се желае в това отношение и е необходимо да се интегрира с продукти като Zabbix / GrayLog / Grafana, за да има функционални и богати средства за мониторинг на състоянието на клъстера и услугите. 
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Използване
    • Време за базово усвояване: 8-12 часа.
    • Необходимост от оперативна поддръжка: ниска до средна (под 6 часа месечно) за системи до 5 физически сървъра и 50 виртуални машини
  • Инсталация на ProxMox – готова дистрибуция – лесна инсталация на сървър (node) в рамките на минути. 
Степен на завършеност / Необходимост от развитие:

  • Напълно завършено решение с всички необходими основни компоненти
  • Следва да се отчита, че наличието на компонент, например система за бекъп, не значи, че наличната система покрива всички възможни случаи
Съвети към IT мениджъра:
  • Струва си. Може да се разчита на ProxMox за изграждане на виртуализационна инфраструктура. 
  • Макар безплатно решение, ProxMox поддържа функционалности, които се реализират в индустриален стандарт като VmWare.
  • Kривата на обучение е приемлива, дори администратори с малко опит бързо усвояват оптималните умения, за да използват ProxMox
  • Разполага с всички необходими компоненти (управление на виртуализация, LXC контейнери, High Availability, Disaster Recovery, Backup, Storage), за бързо изграждане на необходимата инфраструктура.
  • Използването на хипер конвергирана архитектура (сторидж система и виртуални машини споделят едни и същи физически сървъри) предполага добро планиране, изпълнение и непрекъснато наблюдение на пърформанс параметрите на системата.
  • Макар да са налични средствата за backup и организация на HA/DR, необходимо условие е разработването на съответните правила и процедури на ниво IT отдел на организацията. 

IT инфраструктурата на стартираща компания

IT инфраструктурата на стартираща компания

Организация. Принципи. Решения. Управление на риск

1. TL;DR
  • Описани са съображения, принципи и правила при проектиране изграждане и експлоатация на IT инфраструктурата на стартираща компания;
  • Фактори за постигане максимална ефективност при оптимална цена;
  • Управление на IT рискове на стартиращата компания чрез избор на подходящи и изпитани решения;
  • Съвети за идентифициране на проблеми и пестене на време и нерви;
  • Препоръчват се изпитани решения базирани на отворен код.
2. Въведение

Настоящият документ е насочен основно към IT нуждите на технологична компания, но принципите и дизайн насоките са валидни за широк кръг компании, които по необходимост изграждат комплексна IT инфраструктура.

Водещи принципи –

  • Изграждане на необходимата IT инфраструктура, експлоатация гарантираща запазване на интегритет и пърформанс в работата на организацията
  • Оптимизиране на оперативните разходи при различни схеми на организация, включително с присъствени и отдалечени работни места.
  • Внедряване на изпитани решения, за които е натрупан достатъчно експлоатационен опит

Описват се основните положения и добри практики при проектиране и изграждане на виртуализирана, евентуално хиперконвергирана инфраструктура

Целта на документа е да предложи ефективно решение, което може да поддържа дейността на компании от всякакъв мащаб, като гарантира плавно развитие на инфраструктурата съобразно бизнеса на организацията.

Съдържание на: IT инфраструктурата на стартираща компания

The IT infrastructure of Startup company - CONTENTS

 

Можете да получите целия документ след регистрация.

Вашите лични данни ще бъдат обработени съгласно Условията на сайта.

Съгласно Условията на сайта, имате пълни права за използване на файла и информацията в него при съблюдаване на Creative Commons CC BY-SA лизенза. 

 


    Съгласен


    Операни предлага инсталация, интеграция със съществуващи компоненти, експлоатация и поддръжка на комплексни решения за наблюдение и управление в инфраструктура на клиента, публични и частни облаци или върху специализиран Operani Operations Cloud

    OpCenter – Design Guide

    Ръководство за проектиране: Центрове за наблюдение и управление на IT инфраструктури

    Настоящият документ описва основните положения и добри практики при проектиране и изграждане на центрове за наблюдение и управление, например:

    • Service Operation Center
    • Security Operation Center
    • Network Operation Center

    Авторът визира основно центрове за наблюдение и управление в областта на информационните технологии, но голяма част от разглежданите принципи и направени препоръки са приложими и в други сектори.

    Целта на документа е да осигури необходимото ниво на унификация, стандартизация и добри практики, за да се обезпечи безпроблемна и ефективна експлоатация на центровете за наблюдение и управление.

    Авторът си поставя за цел да улесни организациите, които имат необходимост от изграждане на нов, респективно редизайн на съществуващ център за наблюдение и управление.

    В съдържанието и само за пълнота на изложението, са маркирани използваните в един оперативен център софтуерни решения. Те не са развити в този документ.

    Доколкото изграждането и поддръжката на такъв център е свързана с немалки инвестиции в оборудване и персонал, авторът препоръчва и запознаване с документ описващ:

    Документът отразява авторовата експертиза в планирането, изграждането и експлоатацията на големи информационни системи в областта на интернет, телекомуникации и бизнес решения.

    Съдържание на Ръководство за проектиране: Центрове за наблюдение и управление на IT инфраструктури

    OpCenter - Design Guide - CONTENTS

     

    Можете да получите целия документ след регистрация.

    Вашите лични данни ще бъдат обработени съгласно Условията на сайта.

    Съгласно Условията на сайта, имате пълни права за използване на файла и информацията в него при съблюдаване на Creative Commons CC BY-SA лизенза. 

     


      Съгласен


      SLA Калкулатор

      DevOps Roadmap 2020

      Кратко описание

      Това, според Kamran Ahmed, е DevOps технологичният стек за началото на 2020г. 

       

      Съвети към IT мениджъра:
      • Без претенции за всеобхватност и валидност за целия devops спектър, схемата дефинира примерен модел, който може да се следва от технологичните организации за изграждане и поддържане на модерна IT инфраструктура
      • Схемата е особено подходяща за фукционална визуализация на devops и sysadmin процесите в организацията и идентифицирането на необходимите ресурси и технологично ноу-хау
      • Препоръчително е CIO и IT мениджърите да имат предвид или да разработят подобна схема, която да подпомага процеса на търсене на нови и обучение служителите на организацията
      • Не че е невъзможно, но не е препоръчително да реализирате целия технологичен стек без по-тясна специализация и разпределение на роли в екипа

      osTicket

      Кратко описание на osTicket
      • Една от най-популярните системи за поддръжка на клиенти
      • Многостепенна йерархия от агенти за поддръжка
      • Добра система за справки и статистика, която може да се използва за контрол на SLA
      Подходящ за:
      • Изграждане на хелп деск (help desk) / сървис деск (service desk) система за поддръжка на вътрешни и външни за организацията клиенти
      Неподходящ за:
      • В рамките на заеманата ниша, osTicket е подходящ за изграждане на кол център и сървис деск от всякакъв мащаб. 
      За повече информация:
      Защо osTicket:
      • Добре направен и с много мисъл софтуер за организация на IT експлоатация 
      • Достатъчно широка общност от разработчици и потребители
      • Добро API за връзка с трети продукти – например мониторинг системи
      • Множество модули написани от трети страни, които разширяват възможностите му
      • Добре се вписва в корпоративна среда (LDAP/AD) и в политиката за сигурност на компанията
      • Функционален и модерен уеб интерфейс
      Недостатъци:
      • Няма много материали на български език
      Оценка на необходимите ресурси при внедряване:
      • Има относително добра документация за инсталация
      • Време за базово усвояване само на тази функционалност на osTicket: 2-4 часа.
      • Необходимост от оперативна поддръжка: средна (под 4-6 часа месечно, в зависимост от броя поддържани клиенти и възникващи казуси)
      Степен на завършеност / Необходимост от развитие:

      • Завършено решение
      • За пълноценна работа е необходимa инсталация и конфигурация на допълнителни модули, което може да изисква промяна в кода на модулите, ако са разработвани за предишна версия на API
      Съвети към IT мениджъра:
      • Струва си
      • Ако се търси support ticketing system решение с отворен код (open source) – osTicket върши смислена работа

      Fusion Inventory

      Кратко описание

      Fusion Inventory е система за инвентаризация и поддръжка на IT стопанство, която се интегрира със ITSM решения като например GLPI. Инвентаризацията се осъществява чрез поддръжка на SNMP протокол или със специализирани агенти, които се инсталират на машините, които следва да се инвентаризират. Поддържа следните функционалности:

      • Хардуерна и софтуерна инвентаризация 
      • Внедряване на софтуер
      • Wake On LAN функция за извършване на инвентаризация и/или инсталация на софтуер извън нормалните работни часове
      • Откриване на свързан мрежов хардуер (използвайки Netbios, Nmap и SNMP) – например принтери, мрежово оборудване

        Поддържат се различни операционни системи:
      • Windows
      • Linux
      • FreeBSD
      • NetBSD
      • OpenBSD
      • Mac OS X
      • Sun Solaris
      • IBM AIX
      • HP-UX

      Агентът може едновременно да комуникира с различни сървъри на инвентаризационни системи (OCS Inventory, FusionInventory за GLPI, OTRS и др.). 

      Подходящ за:
      • Реализация на система за автоматична инвентаризация, елемент от глобално решение за ITSM
      Неподходящ за:
      • Инвентар и складово стопанство извън IT областта
      За повече информация:
      Защо Fusion Inventory:
      • Агенти, които отнемат много малко ресурси (процесор/памет), поддържат всички популярни операционни системи и даващи възможност да се инвентаризира и държи под контрол стопанството от инсталиран хардуер и софтуер. 
      • Достатъчно широка общност от разработчици и потребители
      Недостатъци:
      • Макар интеграцията с GLPI да е на ниво, web интерфейсът на Fusion Inventory е неинтуитивен
      • Документацията не е особено добра
      Оценка на необходимите ресурси при внедряване:
      • Време за базово усвояване: 2-3 часа
      • Необходимост от оперативна поддръжка: ниска
      Степен на завършеност / Необходимост от развитие:

      • Завършено решение
      Съвети към IT мениджъра:
      • Струва си да се използва в комбинация с GLPI
      • Придава завършеност на GLPI за работа като пълноценна система за инвентар и поддръжка на IT инфраструктура

      GLPI

      Кратко описание на GLPI

      • Предлага пълен комплект IT Service Management (ITSM) средства (ITIL V2)
      • Мощен модул за IT инвентар (IT inventory), включително с автоматично разпознаване (Fusion Inventory) и завеждане в инвентара на компютри, принтери, мрежово оборудване, софтуер, лицензи, консумативи, договори за поддръжка
      • Добър хелп/сървисдеск модул –
        • завеждане/отваряне на тикети през различни канали (мейл, уеб, може да се правят и други).
        • Разпределяне на задачи към вътрешни и външни изпълнители.
        • Knowledge base.
        • SLA контрол
        • Call center решение може да се направи с комерсиални модули за интегриране със софтуерна телефонна централа (Asterisk)
      • Проджект мениджмънт модул
      • Универсална система с широка приложимост в рамките на голяма организация
      Подходящ за:
      • Базови ITSM процеси (ITIL V2)
      • Изграждане на система за поддържане на IT складово стопанство – инвентар (inventory) с ръчно и автоматично въвеждане на информацията
      • Изграждане на хелп деск (help desk) / сървис деск (service desk) система за поддръжка на вътрешни и външни за организацията клиенти
      Неподходящ за:
      • Инвентар и складово стопанство извън IT областта
      За повече информация:
      Защо GLPI:
      • Добре направен и с много мисъл софтуер за организация на IT експлоатация 
      • Достатъчно широка общност от разработчици и потребители
      • Удобен за SLA контрол
      • Добро API за връзка с трети продукти – например мониторинг системи
      • Множество модули написани от трети страни, които разширяват възможностите на GLPI
      • Добре се вписва в корпоративна среда (LDAP/AD) и в политиката за сигурност на компанията
      Недостатъци:
      • Web интерфейсът не е особено интуитивен и изглежда архаичен
      • Макар да има няколко андроид базирани безплатни мобилни клиента, нито един от тях не предоставя цялостно мобилно решение. Платените клиенти не си заслужават
      • Няма много материали на български език
      • Добра документация има на френски език. Документацията на английски език върши работа, но има липси
      • Тъй като API-то за връзка с допълнителни модули и външни системи е променяно неколкократно през годините – случват се несъвместимости
      Оценка на необходимите ресурси при внедряване:
      • Има относително добра документация за инсталация
      • Изисква ръчна инсталация на базови компоненти (database, web server) и на множество php модули
      • Лек е за експлоатация
      • Време за базово усвояване: 4-6 часа
      • Необходимост от оперативна поддръжка: средна (под 4-6 часа месечно, в зависимост от типовите системи и устройства, които се инвентаризират)
      • При използване на модули от трети страни може да се направи добро call center решение за IT поддръжка 
      Степен на завършеност / Необходимост от развитие:

      • Завършено решение
      • За пълноценна работа е необходимa инсталация и конфигурация на допълнителни модули, което може да изисква промяна в кода на модулите, ако са разработвани за предишна версия на API
      Съвети към IT мениджъра:
      • Струва си
      • Ако се търси ITSM решение с отворен код (open source) – GLPI върши смислена работа

      Операни предлага инсталация, интеграция със съществуващи компоненти, експлоатация и поддръжка на комплексни ITSM решения в инфраструктура на клиента, публични и частни облаци или върху специализиран Operani Operations Cloud