Tag: Operations

Домашен дейтацентър или лаборатория|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). Това е постоянен процес, а не еднократно планирана и извършена работа. Добрата съвместната работа с дейта център оператора е от ключово значение за този процес
  • Доколкото смяната на дейта център е изключително тежко, времеемко и с множество скрити разходи упражнение, добрият избор е от бизнес критично значение

Traccar

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

Traccar е Java базиран GPS tracking сървър. Поддържа практически всички популярни протоколи и устройства и е изключително подходящ за организации, които искат да следят, визуализира и анализират движението на устройства и превозни средства.

Вградените му възможности за визуализация и анализ го правят приложим както за автоматизация дейността на център за експлоатация в организацията, но така също и за извършване на бизнес анализ в областта на проследяването на превозни средства (AVL – Automatic Vehicle Location).

Подходящ за:
  • Бизнес аналитична дейност в организацията
  • AVL
  • Споделяне на информация в организацията и външни потребители
  • Поддръжка на активни и атрактивни табла за визуализация
  • Изпращане на съобщения при достигане или промяна на ключови параметри 
Неподходящ за:
  • В размките на своята ниша, Traccar е подходящ за всички дейности
За повече информация:
Защо Traccar:
  • Предлага цялата си функционалност в безплатна версия
  • Документацията е на приемливо ниво
  • Интеграция с LDAP
Недостатъци:
  • Traccar е монолитно java приложение и предполага грамотно поддържана база данни и сървърен ресурс
Оценка на необходимите ресурси при внедряване:
  • Лесно и бързо внедряване
Степен на завършеност на решението:
  • Завършено
Съвети към IT мениджъра:
  • Струва си – Traccar е функционална AVL система

NextCloud

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

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

Поддържа се висок клас криптиране и защита на информацията, което позволява използването на NextCloud дори в корпоративна среда.

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

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

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

Поддържа:

  • Разширени възможности за мониторинг
  • Пълнотекстово търсене
  • Kerberos authentication
  • Аудио/видео конферентни разговори
  • Федерация (обединение на различни) NextCloud сървъри

Базова функционалност

  • calendars (CalDAV)
  • contacts (CardDAV)
  • streaming media (Ampache)
  • browser-based text editor
  • bookmarking service
  • URL shortening suite
  • gallery
  • RSS feed reader
  • document viewer tools from within Nextcloud
  • connection to Dropbox, Google Drive and Amazon S3
Подходящ за:
  • Групуеър решение за организация, отдел, фирмено или персонално ниво
  • Съвместна работа върху документи “а ла Гугъл драйв”
  • Вградените механизми за споделяне на файлове осигуряват и добър контрол на достъпа до тях.
  • Добре се вписва в корпоративна политика за достъп и организация благодарение на поддръжката на OpenID или LDAP
Неподходящ за:
  • В размките на своята ниша, NextCloud е подходящ за всички дейности
За повече информация:
Защо NextCloud:
  • Предлага цялата си функционалност в безплатна версия
  • Документацията е на приемливо ниво
  • Интеграция с LDAP
  • Множество безплатни разширителни модули
Недостатъци:
  • Комплексно приложение, изискващо поддръжка на ниво операционна система. 
Оценка на необходимите ресурси при внедряване:
  • Относително лесно и бързо внедряване. 
  • Интеграцията с някои допълнителни модули (например Only Office) може да е предизвикателство
Степен на завършеност на решението:
  • Завършено
Съвети към IT мениджъра:
  • Струва си – NextCloud е завършено групуеър решение и може да се използва като заместител на Google Drive в рамките на организация. 

Redash

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

Redash е инструмент за бизнес анализ с отворен код. Свързва се към използваните в организацията бази данни и чрез вградения SQL редактор позволява създаване на справки (отчети, табла за визуализация (dashboards) и известия (alerts). Получените резултати могат да бъдат представяни в табличен вид, като различни графики или карти.  

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

Redash позволява:

  • Агрегиране на знания на ниво организация или отдел в нея.
  • Лесно споделяне на знанието между различни екипи и потребители
  • Улеснява 

Поддържани бази данни

  • Amazon Athena
  • Amazon Aurora
  • Amazon DynamoDB
  • Amazon Redshift
  • Axibase TSDB
  • Azure Data Explorer (Kusto)
  • Cassandra
  • ClickHouse
  • Druid
  • Elasticsearch
  • Google BigQuery
  • Graphite
  • Greenplum
  • Hive
  • Impala
  • InfluxDB
  • MemSQL
  • Microsoft SQL Server
  • MongoDB
  • MySQL
  • Oracle
  • PostgreSQL
  • Presto
  • Rockset
  • ScyllaDB
  • Snowflake
  • TreasureData
  • Vertica

Интеграции с:

  • Google Analytics
  • Google Spreadsheets
  • JIRA
  • JSON
  • Python
  • Salesforce
  • Yandex AppMetrica
  • Yandex Metrica
Подходящ за:
  • Бизнес аналитична дейност в организацията
  • Има възможност за едновременна работа с различни източници (бази данни) – т.е. възможно е да се прави join между таблици в различни бази данни
  • Уеб базиран фронтенд към множество бази данни, който позволява визуална обработка на информацията (visual queries)
  • Споделяне на информация в организацията и външни потребители
  • Поддръжка на активни и атрактивни табла за визуализация
  • Изпращане на съобщения при достигане или промяна на ключови параметри в базите данни и направените справки
  • Бързо прототипиране на анализ/представяне на информация за проекти, които не изискват самостоятелна система за тази цел
Неподходящ за:
  • Не заменя комерсиални средства за бизнес аналитична дейност, макар да предоставя много от тяхната функционалност
За повече информация:
Защо Redash:
  • Предлага цялата си функционалност в безплатна версия
  • Има комерсиална версия и разширена поддръжка
  • Документацията е на приемливо ниво
Недостатъци:
  • Няма широка база от разработчици
  • Няма възможност за визуална работа с базата данни
  • Доколкото много от обработките се правят в паметта, работата с големи обеми от данни може да създаде проблеми
Оценка на необходимите ресурси при внедряване:
  • Предлагат се различни и удобни възможности за внедряване – docker контейнери или инсталационен скрипт – инсталацията е лесна и бърза
  • Началната конфигурация отнема минути, след свързване към източниците на информация
  • Пълните възможности на Redash предполагат и напреднали познания принципно за бази данни и конкретно за използваните такива в организацията
Степен на завършеност на решението:
  • Завършено
Съвети към IT мениджъра:
  • Струва си – Redash дава бърз достъп и анализ на информационните масиви на организацията
  • Възможността за споделяне и преизползване на полученото знание подобрява ефективността на организацията
  • Redash може да разтовари отделите, които управляват знанието в организацията, давайки възможност крайните потребители на информацията да имат директен достъп до нея 
    • Т.е. не се налага заявка и чакане за предоставяне на нов тип справка
  • Възможността за едновременна работа с различни източници, дава възможност за много ефективна интеграция на използваните в организацията бази данни

Metabase

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

Metabase е инструмент за бизнес анализ с отворен код. Свързва се към използваните в организацията бази данни и позволява визуално или чрез SQL код създаване на справки (наричани в терминологията на Metabase “въпроси”), отчети, табла за визуализация (dashboards) и известия (alerts). Получените резултати могат да бъдат представяни в табличен вид, като различни графики или карти. Разполага с мощни средства за автоматичен анализ на суровите данни, който подпомага работата на потребителите. 

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

Метабейс позволява:

  • Агрегиране на знания на ниво организация или отдел в нея.
  • Лесно споделяне на знанието между различни екипи и потребители
  • Улеснява 

Поддържани бази данни

  • BigQuery
  • Druid
  • Google Analytics
  • H2
  • MongoDB
  • MySQL
  • PostgreSQL
  • Presto
  • Amazon Redshift
  • Snowflake
  • Spark SQL
  • SQLite
  • SQL Server
Подходящ за:
  • Бизнес аналитична дейност в организацията
  • Уеб базиран фронтенд към множество бази данни, който позволява визуална обработка на информацията (visual queries)
  • Споделяне на информация в организацията и външни потребители
  • Поддръжка на активни и атрактивни табла за визуализация
  • Изпращане на съобщения при достигане или промяна на ключови параметри в базите данни и направените справки
  • Бързо прототипиране на анализ/представяне на информация за проекти, които не изискват самостоятелна система за тази цел
Неподходящ за:
  • Не заменя комерсиални средства за бизнес аналитична дейност, макар да предоставя много от тяхната функционалност
За повече информация:
Защо Metabase:
  • Зрял проект с дългогодишно устойчиво развитие 
  • Предлага цялата си функционалност в безплатна версия
  • Има комерсиална версия, която е повече насочена към white label решение с повече интеграции и разширена поддръжка
  • Документацията е на приемливо ниво
  • Добре се вписва в корпоративна среда (LDAP) и в политиката за сигурност на компанията – позволява прецизно управление на достъпа до обработената информация (справки, табла) и предоставя възможност за изолация на същинските данни (може да се филтрира достъпът до суровата информация в самите бази данни)
Недостатъци:
  • Няма широка база от разработчици
  • Липсва (все още) възможност за едновременна работа с повече източници (например join между таблици от различни бази данни)
  • Има ограничения в размера на информацията, която може да визуализира (до 10000 реда)
Оценка на необходимите ресурси при внедряване:
  • Предлагат се различни и удобни възможности за внедряване – docker контейнер или jar файл. инсталацията е лесна и бърза
  • Началната конфигурация отнема минути, след свързване към източниците на информация
  • Пълните възможности на Метабейс предполагат и напреднали познания принципно за бази данни и конкретно за използваните такива в организацията

 

Степен на завършеност на решението:

  • Завършено решение
Съвети към IT мениджъра:
  • Струва си – Metabase дава бърз достъп и анализ на информационните масиви на организацията
  • Възможността за споделяне и преизползване на полученото знание подобрява ефективността на организацията
  • Метабейс може да разтовари отделите, които управляват знанието в организацията, давайки възможност крайните потребители на информацията да имат директен достъп до нея при спазване на политиките за сигурност
    • Т.е. не се налага заявка и чакане за предоставяне на нов тип справка

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

AI Based Log Processing using LLM

Събиране, обогатяване и обработка на логове чрез решения с отворен код. Анализиране, обясняване и откриване на аномалии в логове с използване на големи езикови модели.

Open source collection, decoding and enriching logs. Analyzing, explaining and anomaly detection using large language models (LLM)

В тази статия представяме примерно решение (Proof of Concept), базирано изцяло на технологии с отворен код и имплементирано локално в собствена инфраструктура.

Обработката на логове с използване на AI технологии и по-специално големи езикови модели (LLM) е изключително активно развивано в последно време. По разбираеми причини, преобладават комерсиални разработки и се предлагат предимно като клауд базирани услуги на съответните доставчици (Elastic, Splunk, ATT Cybersecurity и много други).

Основните принципи на представеното решение са:
  • Събиране на широк набор от логове, например:
    • Системни логове (syslog) – Linux, Windows, Mac
    • Логове от приложения (например уеб сървъри)
    • Инсталационни логове / Install logs
    • Логове от мрежови устройства / Network logs
    • Логове от файъруоли / Firewall logs
    • HIDS (Host Intrusion Detection Systems) и NIDS (Network Intrusion Detection Systems) logs
  • Обогатяване на логовете, например:
    • Добавяне на геолокация по IP адрес
    • Корелация на събития
  • Локална обработка на логове – макар да е възможна реализация на системата в публични клауд услуги, ако организацията желае да упражнява пълен контрол над своите логове, те може да се събират, обработват и съхраняват локално
  • Евтино дългосрочно съхраняване на събраната информация – без зависимост от ценовата политика и ограниченията на доставчици на решения за обработка на логове
  • Възможност за AI обработка на логове с използване на локални големи езикови модели (Local LLM), това позволява:
    • Контрол над разходите – при комерсиалните езикови модели се заплаща на “token” входяща и изходяща комуникация със съответния модел.
      • За сравнение – ако се използва комерсиален LLM, едно изпълнение на описаната по-долу обработка на логове (доста ограничена по обем) през API на OpenAI ще струва около $0.1 – интензивната обработка на големи обеми логове е с доста висока себестойност при използване на комерсиални решения
      • Контрол на информацията –
        • Логовете на компанията не излизат извън неин контрол/юрисдикция
        • Чувствителна по отношение на сигурността информация не излиза извън рамките на компанията
        • Комерсиалните доставчици на LLM не използват тази информация за обучение на своите модели
      • По-високо бързодействие – то изцяло зависи от използвания ресурс, а не от споделеното използване на клауд услуга
Лог процесори

Съществуват множество популярни опън сорс средства за събиране и обработка на логове (за които имаме статии в блога), например:

  • Те осигуряват декодиране на логовете, обогатяване с допълнителна информация и прилагане на правила и корелации (rules and correlations), с които редуцираме обема на информацията за анализиране, което оптимизира бързодействието на езиковите модели, качеството и себестойността на анализа.
Тестова постановка
  • За събиране, обработка и обогатяване на логовете използваме Wazuh
    • Wazuh позволява да редуцураме излишния шум и се съсредоточим само до тип и клас събития, които са важни
  • LLM (Large Language Model) – за гарантиране сигурността на логовете (не напускат нашия контрол) и контрол на разходите използваме допълнително настроен (fine tuning) LLM базиран на mistral-7b.
    • Добри резултати се получават и с Qwen1.5 или Phi-3-Minи.
    • За фина настройка са използвани access, setup, file logs и допълнителна информация като описание на команди и дефиниране на потенциални заплахи и рискови състояния
  • Работа с локални LLM – този въпрос не се разглежда поради тривиалност. Има много статии по въпроса, добра отправна точка е тази статия:
  • Обработка на лог събития с LLM – използва се LangChain
  • Използван хардуер
    • Wazuh – според препоръките за размер на необходимата инфраструктура
    • GPU server за поддръжка на локален LLM (Large Lаnguage Model)
      • GPU: Nvidia 30xx, 40xx, Axxxx
        • Поне 16GB VRAM
        • Препоръчително 24GB VRAM
        • Оптимално 32-48GB VRAM
Експеримент
13:38:38 - ps ax |grep ps
13:38:42 - exit
13:38:44 - w
13:38:50 - last
13:39:00 - ls -lah
13:39:21 - chmod 770 nmapscan.py
13:39:40 - joe nmapscan.py
134:0:49 - ./nmapscan.py
13:40:33 - passwd
13:40:37 - w
Jun 12, 2024 @ 13:40:33.262	Command: “  165  passwd” executed by root in logai1	
Jun 12, 2024 @ 13:39:49.400	Command: “  164  ./nmapscan.py” executed by root in logai1	
Jun 12, 2024 @ 13:39:49.400	Command: “  163  joe nmapscan.py]” executed by root in logai1		
Jun 12, 2024 @ 13:39:40.792	Command: “  163  joe nmapscan.py” executed by root in logai1	
Jun 12, 2024 @ 13:39:21.183	Command: “  162  chmod 770 nmapscan.py” executed by root in logai1	
Jun 12, 2024 @ 13:39:00.751	Command: “  161  ls -lah” executed by root in logai1	
Jun 12, 2024 @ 13:38:50.740	Command: “  160  last” executed by root in logai1	
Jun 12, 2024 @ 13:38:44.734	Command: “  159  w” executed by root in logai1		
Jun 12, 2024 @ 13:38:42.738	Command: “  158  exit” executed by root in logai1	
Jun 12, 2024 @ 13:38:38.733	Command: “4  ps ax |grep ps” executed by user in logai1	
  • Промпт към LLM – имаме следните цели:
    • Ясна задача
    • Предотвратяване на халюцинации
    • Недопускане на отклонения
    • Дефиниране на нормалност
I need help analyzing logs of Linux commands used by a user to identify and explain anomalies in their behavior. The logs include fields such as timestamp, user ID, command executed, and any relevant command arguments or output.

Normal user behavior typically involves:
- Common commands like but not limited to "ls", "cd", "grep", "cp", and "rm"
- Execution of commands between 8 AM and 8 PM
- Commands executed in typical sequences (e.g., "cd" followed by "ls")

Agent in these logs means the name of the computer audited.

I am interested in detecting anomalies such as:
- Execution of unusual or rarely used commands (e.g., "iptables", "shutdown", "chmod 777")
- Commands executed at unusual times (e.g., late night or early morning)
- Unexpected sequences of commands (e.g., "rm -rf" followed by "shutdown")
- Commands that could compromise security or system stability

Specific metrics to focus on:
- Frequency of security-related commands (e.g., "iptables", "passwd")
- Time intervals between potentially harmful commands
- Deviations from normal command sequences

The analysis should cover the log period and be presented with summary statistics, text based visualizations, and detailed explanations of identified anomalies, including the purpose of the command and its potential impact on security or stability.

  • Получен анализ от LLM
Analyzing the provided logs from the user on the system "logai1," we can observe several commands executed and identify any anomalies or unusual patterns based on the typical user behavior and security considerations. Here's a detailed breakdown:
### Log Summary:
1. **Command Execution Times**: All commands are executed between 13:38 and 13:40, which falls within the normal operational hours (8 AM to 8 PM).
2. **Command Frequency and Sequence**:
   - Common commands like ps, w, last, ls, and exit are used.
   - Security-sensitive commands like chmod, passwd, and execution of a script (./nmapscan.py) are noted.
   - Use of the text editor joe to edit nmapscan.py.
### Detailed Analysis:
1. **ps ax | grep ps**:
   - **Purpose**: Lists all running processes and filters for processes related to ps.
   - **Impact**: Generally harmless, used for monitoring or checking processes.
2. **exit**:
   - **Purpose**: Exits the terminal session or a shell.
   - **Impact**: Normal command, no security implications.
3. **w**:
   - **Purpose**: Shows who is logged on and what they are doing.
   - **Impact**: Common monitoring command, no direct security implications.
4. **last**:
   - **Purpose**: Displays a list of last logged in users.
   - **Impact**: Used for checking recent accesses, harmless unless used to track other users' activities for malicious reasons.
5. **ls -lah**:
   - **Purpose**: Lists all files in the current directory in a detailed format.
   - **Impact**: Common command, typically harmless.
6. **chmod 770 nmapscan.py**:
   - **Purpose**: Changes the permissions of the file nmapscan.py to allow full permissions for the owner and group, and no permissions for others.
   - **Impact**: Security-sensitive as it modifies access rights, especially relevant if nmapscan.py is a critical or sensitive file.
7. **joe nmapscan.py**:
   - **Purpose**: Opens the file nmapscan.py in the Joe editor for editing.
   - **Impact**: Depends on the content of nmapscan.py. If it's a script related to network scanning, modifications could be sensitive.
8. **./nmapscan.py**:
   - **Purpose**: Executes the Python script nmapscan.py.
   - **Impact**: Highly sensitive depending on the script's function. If it's used for network scanning, it could be used for security assessments or potentially unauthorized network activities.
9. **passwd**:
   - **Purpose**: Changes the user's password.
   - **Impact**: Highly sensitive, especially if used without proper authorization. Could indicate an attempt to secure an account after unauthorized access or to change another user's password.
### Anomalies and Concerns:
- **Execution of chmod 770 nmapscan.py and subsequent execution of nmapscan.py**: This sequence suggests preparation and execution of potentially impactful scripts, which could be used for network scanning or other activities that might affect system/network security.
- **Use of passwd**: Needs to be validated if it was authorized. Frequent or unauthorized use can be a security concern.
### Recommendations:
- **Review the purpose and content of nmapscan.py** to ensure it complies with organizational policies.
- **Audit the use of passwd** to confirm it aligns with security policies and that there was no unauthorized access.
- **Monitor for further use of sensitive commands** (chmod, passwd, script executions) to detect any pattern that might suggest malicious intent or policy violation.
This analysis should be integrated into regular security audits to ensure continuous monitoring and quick response to potential security incidents
Известия
  • Крайният резултат – анализите извършени от LLM се предостяват чрез mail или messenger (Slack, Telegram…) интеграция.
    • Удобно за служители по сигурността и оперативни мениджъри е получаването на резюме за събития с отношение към информационната сигурност на регулярни интервали от време, примерно веднъж дневно
    • За оператори на системи за сигурност системата може да работи и предоставя анализи в реално (или близко до реално време с оглед необходимостта да се правят корелации и детекция на аномалии във времето).

Коментари и изводи
  • LLM са доста ефективни и полезни за анализиране и обясняване на предварително обработена лог информация.
  • Откриването на аномалии работи при добре изчистена информация, в зависимост от качеството на използвания промпт, но следва да се приема критично и да не се счита за окончателно
    • Критично важно е LLM да получава добре изчистени от шум логове
  • Възможността им да редоставят кратки резюмета и/или подробни анализи на информация и събития е изключително полезна, както за оперативни ръководители в сферата на информационната сигурност и IT операции, но също така и за оперативен персонал в сферата на сигурността
  • Доколкото производителността на езиковия модел (необходимото за извършване на анализ време), както и себестойността (при локални модели – капиталовия и оперативен разход за поддръжка на необходимата IT инфраструктура)) зависят от обема на обработваната информация, силно препоръчително е подаването не на обща, а на максимално изчистена от шум и обогатена с метаданни (например IP геолокация) лог информация.
    • Тоест използването на добре настроена SIEM система (например Wazuh) е изключително важно
  • Текущ недостатък на LLM е склонноста им към халюцинации и отклонение от инструкциите с течение на времето. Този процес следва да се следи и да се управлява чрез наличните методи (понастоящем активно се работи в тази посока, при развитие на технологиите ще допълним статията)
  • Фино настроени свободно достъпни локални LLM показват сравними с резултатите на комерсиалните модели, все пак следва да се отчита:
    • Комерсиалните модели се справят по-добре при неоптимални промптове, респективно добрите промптове са ключ към ефективността
    • Комерсиалните модели се справят по-добре с голям обем информация (заради по-широките си контекстуални прозорци (conеtxt window).
      • Следва да се отчита, че използването на по-широки контекстуални прозорци при локалните модели предполага повече GPU памет и по-голяма нужда от производителност на хардуера
      • В тази връзка, предварителната обработка на информацията, намаляването на обема и, шума, както и допълнителното и обогатяване са ключ не само за себестойността, но и за нейното качество и като цяло ефективност на концепцията.

Необходима експертиза за реализация на подобно решение
  • Компонент Log processing – DevOps/SysAdmin експертиза и сериозен опит в обработка на логовеи сериозен опит в обработка на логове
  • Компонент LLM – базово Python програмиране

Препоръка
  • AI Based Log Processing using LLM, дори понастоящем, е доста зряла технология и вече си струва широкото и имплементиране с цел:
    • Намаляване натоварването на персонал
    • Повишаване възможностите за обработка и детекция на аномалии
    • Повишаване видимостта върху процеси свързани със сигурността
      • Това е особено полезно за мениджъри в областта на информационна сигурност и експлоатация
      • Подпомага процесите на сертификация, ресертификация и вътрешен одит в областта на информационната сигурност
    • Автоматизация на дейности в областта на информационната сигурност, които изискват ниска квалификация
  • Все пак следва да се отчитат недостатъците на LLM – халюцинации, отклоняване и техните анализи да се приемат критично и да не се считат за пълни и/или окончателни

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

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 върши смислена работа

Zulip chat

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

Zulip chat е чат приложение за работни групи – подобно е на Slack, Mattermost, MS Teams и прочие.

Предлага:

  • Оптимални система за визуализация на съобщения
    • Метаезик оптимизиран за групов чат с четимо и удобно представяне на съобщенията
    • Представяне на снимки и видео клипове
    • Drag and drop работа с файлове
    • Визуализация на код, включително syntax highlighting
  • Мощна система за нотификации, включително през мобилни и десктоп клиенти, мейл. нотификация по конкретни теми, участници в дискусия, ключови думи и прочие
  • Клавишни шорткъти за удобство и скоростна работа
  • Интеграция със стотици приложения и системи
  • Бизнес клас сигурност
  • Пълнотекстово търсене
  • История на чатове
  • Статистики
  • Частни разговори
  • Видео разговори
  • Модерация
  • Интеграция с други чат системи (например Slack, IRC, Matrix)
  • Много, много други възможности
Подходящ за:
  • Изграждане на фирмена чат система
  • Безплатна алтернатива на Slack – при надхвърляне на рамките,  в които Slack е безплатен
Неподходящ за:
  • Система за индивидуален чат
За повече информация:
Защо Zulip chat:
  • Предлага цялата си функционалност в безплатна версия
  • Има клауд базирана комерсиална версия (подобно на Slack)
  • Документацията е на приемливо ниво
  • Интеграция с LDAP
  • Интеграция със системи за наблюдение и управление
  • Собственост е и активно се развива от DropBox
Недостатъци:
  • Дребни проблеми при работа с мобилния клиент под Андроид.
    • Доколкото приложението се развива активно, те вероятно са отстранени към момента на четене на статията
  • Липса на документация на български език
Оценка на необходимите ресурси при внедряване:
  • Време за инсталация: 45 мин
  • Време за базово усвояване: 1 час
  • Необходимост от оперативна поддръжка: ниска
Степен на завършеност / Необходимост от развитие:

  • Завършено решение
Съвети към IT мениджъра:
  • Струва си да се използва като безплатна алтернатива на Slack и MS Teams.
  • В някои отношения е по-добре замислен и изпълнен
  • Възможностите за интеграция с други приложения и системи са огромни и близки до тези на основният конкурент – Slack

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