Тернистий шлях ITSM в Росії

20 березня 2015 року було чергове сонячне затемнення. Офісні працівники центральної та північно-західної Росії намагалися його розгледіти: через сонячні окуляри, тонування автомобіля, пивну пляшку. І тільки спритні запасливі адміни відсували шторку дискет і з насолодою передавали з рук в руки рятівну плівку. А адже зовсім недавно підписані дискети були одним з найважливіших носіїв інформації — на них здавали курсові, носили звіти і вивантаження з відділу у відділ, з них завантажували програми. З дискетами в руках ще недавно радянська Росія відкривала капіталізм. Попереду були мережі, доступний інтернет, зовнішні жорсткі диски, флешки і неймовірна кількість пов'язаних з цим проблем. Сьогодні ми віддамося ностальгії, а заодно згадаємо, як розвивалися системи управління ІТ-активами.



Повний штиль
Мережева ІТ-інфраструктура сучасного підприємства — це вже давно не мережі і канали передачі даних. Офісні мережі порозумнішали, обросли можливостями віртуалізації і стали програмно-конфігуруються (мова йде про Software Defined Networks, SDN, коли рівні управління мережею передачі даних поділяються за рахунок перенесення функцій управління (маршрутизатори, комутатори тощо) програми, що працюють на окремому сервері (т. зв. контролері). ІТ-вендори пропонують незліченна кількість інструментів, найскладніші архітектури і одночасно — програмні продукти для моніторингу і контролю за всім цим набором.

В доперебудовний період як таких засобів моніторингу не вимагалося: комп'ютери широко використовувалися тільки у великих організаціях, де кожен працівник ніс відповідальність за свої дії, а спокус у вигляді інтернету або бажання поставити неліцензійний Фотошоп просто не було. Всі хуліганство зводилося до невинних жартів на кшталт роздрукування картинок на промислових принтерах (пам'ятаєте «Джоконду» над столом секретарки Вірочки з фільму «Службовий роман»?). У більш ранні періоди не було і цього.


Розробка першої малої електронної лічильної машини в СРСР почалася восени 1948 року. 25 грудня 1951 р. МЕСМ була прийнята комісією Академії наук СРСР під головуванням легендарного академіка М. В. Келдиша і передана в експлуатацію. В грудні 1951 р. практично одночасно і незалежно в Радянському Союзі були виготовлені і введені в експлуатацію дві перші електронні цифрові машини: автоматична цифрова обчислювальна машина АЦВМ М-1 в Росії і мала електронна лічильна машина «МЭСМ» в Україні. АЦВМ М-1 і «МЭСМ» відкрили початок практичної реалізації створення цифрових обчислювальних машин у СРСР:

Навесні 1952 р. почалися розробка і виготовлення швидкодіючої універсальної ЕОМ М-2, а в 1953 році з'явилася швидкодіюча електронна обчислювальна Машина загального призначення БЭСМ-1 (середня продуктивність — 8000-10000 операцій в секунду). Машини поставлялися без системного і використовувалися підприємствами і обчислювальними центрами спершу для обчислювальних операцій (це були наукові дослідження і облік показників народного господарства). Пізніше машини радянської розробки, а потім і перші комп'ютери IBM в СРСР використовувалися в обороні, космічній сфері, для обліку даних та навіть для запуску і використання перших автоматизованих систем управління (АСУ). Комп'ютерами управляли оператори і у них, на відміну від наших з вами сучасників, не було можливості (та й потреби) підключити до комп'ютера носій із зараженими файлами або зробити що-небудь, крім того, як, наприклад, вивести на друк свою дисертацію. У той час роздруківка якої-небудь книги або репродукції (як на прикладі з фільму) була єдиним неправомірним використанням службового комп'ютера.

Пірати молодий Росії — методи захисту ПЗ в кінці 80-х
Одна з перших проблем, з якою зіткнувся СРСР в останні роки свого існування (приблизно з 1988 року) і яку успадкувала новонароджена Російська Федерація, була проблема використання неліцензійного програмного забезпечення (простіше кажучи, піратства). Разом з піратством в компанії і університети прийшли загрози зараження вірусами, а виробникам — питання захисту авторських прав та несанкціонованого копіювання. Вже тоді почали з'являтися перші механізми захисту. Одні з них пережили добрі 25 років і успішно застосовуються до цих пір, інші викликають у сучасних розробників посмішку. (Розділ про методи захисту написаний з використанням інформації збірника БІТ, випуск 3, М.: ИнфоАрт, 1991 р. — прим. ред.)


Захист з допомогою серійного номера. Забезпечується наявність унікального номера у кожному примірнику програми. При копіюванні програми на носій (а на початку 90-х це були здебільшого дискети) в неї заноситься порядковий номер, який потім проставляється на реєстраційній картці продажу цієї програми конкретному покупцеві. При виявленні копії програми у незареєстрованого користувача можна знайти джерело викрадення програми і навіть простежити ланцюжок. Впевнений, багато хто з вас ще встигли зареєструвати подібні картки для правових та бухгалтерських систем. У своєму первісному вигляді (наявність унікального номера у кожному примірнику) цей спосіб не використовується ніким з того моменту, як екземпляри програми перестали записувати вручну на магнітний носій.

Захист лічильником встановлених копій (і знову ми можемо побачити спадщина цього методу в деяких вендорів, але з поправкою на електронну постачання). Компанії постачали носії з заздалегідь обговоренным числом копій, які можна отримати з дистрибутивної (поставочной) дискети. Як правило, для такого продукту існує зашита програма установки (інсталяції), яка при черговому копіюванні зменшує лічильник числа копій. Якщо ж основну програму скопіювати без інсталяції, то така копія, в кращому випадку, не буде працювати. Не можна також скопіювати і всю дискету з настановної програмою, так як програма установки перевіряє оригінальність дискети, на якому вона записана. В основному такий захист застосовують на ігрових програмах. Цей вид захисту інколи поєднувався з захистом серійним номером. Саме такий метод можуть згадати любителі легендарної гри Ice Hockey.

У чистому вигляді серійний номер — це застаріла технологія і шалено примітивний механізм, який легко ламається з допомогою реверс-інжинірингу. Власне, саме так і створювалися генератори ключів для популярних додатків (кейгены).

Але можливість зробити хороший захист на основі серійного номера зберігається. Сьогодні активація програм відбувається за іншої моделі: кількість інсталяцій для кожної ліцензії вважається на сервері виробника, для чого при введення серійного номера потрібно пройти процедуру активації онлайн. Наприклад, так робить Microsoft.

Програмна захист від дизассемблирования. Практично будь-який захист можна зняти або обійти: що в 90-е, що в 2016 році. Тому необхідно вжити заходів, щоб програми для злому потрібні серйозні витрати, порівнянні з покупкою. Тим більше, що в Росії були прецеденти, пов'язані з дорогим зломом — спроби підламати 1С, захищений апаратним ключем (донглом). Але це поодинокі випадки.


Як розкривалися програми з допомогою дизассемблирования?
  • Пряме побудова за завантажувального модуля тексту програми на асемблері або іншою мовою. Після цього з тексту видаляються підпрограми перевірки і будується заново завантажувальний модуль. Погодьтеся, трудомістке і вимагає роботи добре оплачуваної професіонала.

  • В завантажувальному модулі відладчиком простежується система захисту, а потім в модуль вносяться такі зміни, щоб відповідна підпрограма вже не змогла активізуватися.


  • За допомогою відладчика програма завантажується в ОЗУ, проходяться всі ступені захисту, і в момент завершення роботи програми захисту на диск записується копія ОЗУ, щоб надалі можна було завантажити з диска програму з пройденим етапом захисту.

  • Апаратна трасування за допомогою внутрісхемних емуляторів або логічних аналізаторів з блоками для трасування.

Втім, придбати ліцензію найчастіше виявлялося дешевше, безпечніше і доцільніше.

Використання технічних відмінностей в машині для програмної захисту — ще один примітний і досить інтелектуальний спосіб захисту. Як правило, кожна модель ПК (ЕОМ) має свої індивідуальні особливості. Це можна було використовувати для перевірки унікальності комп'ютера, на якому встановлена програма.

Докладніше
  • При копіюванні програма записувалася в довільне місце на гнучкому диску (для MS-DOS). Якщо не дізнатися, на які фізичні сектори зроблено запис, практично неможливо перенести програму на інший диск. Ця захист використовувалася для боротьби з чорним копіюванням ще в часи пізнього СРСР, і померла разом з дискетами.

  • Спеціальна обробка конкретного біта на диску (мова йде виключно про гнучких дисках (дискетах)), поверхня яких була доступна і на яку можна було довільно впливати). При нормальному читанні диска відбувається аналіз: якщо є магнітний сигнал, – 1, немає – 0. А якщо сигнал слабкий? Тоді зчитування десять раз дає, припустимо, три рази 1, а сім разів – 0. Можна записати такий слабкий сигнал, а потім перевіряти його.


  • Пропалювання лазером (або проколювання) отвори в оригінальній дискеті за заздалегідь визначеною адресою. Під час перевірки робиться спроба запису 1 за такою адресою і зчитування її. Якщо вважалася 1, то це копія, а не оригінал.

  • Проводиться опитування пароля при завантаженні програми, причому сам пароль не зберігається в програмі, а обробляється введена рядок і по отриманому адресою викликається наступна виконується підпрограма. У випадку помилки ймовірність вірного входу мізерно мала.

Використання програмно-апаратного захисту. Вона аналогічна програмної, але вимагає великих зусиль при знятті.

  • Установка на порт спеціальної заглушки, що містить мікросхему і, можливо, елемент живлення. Програма перевіряє наявність цієї заглушки, використовуючи спеціальний протокол обміну між ними. Зняття захисту полягає або в імітації заглушки, або в її відтворенні, або виявлення та нейтралізації підпрограми перевірки її наявності. Цей метод прогресивний через можливості використання замовний БІС.

  • Наявність плати захисту, що вставляється в слот ПЕОМ. Цей захист практично неможливо обійти, але така плата занадто дорога для широкого застосування і використовується виключно в дорогому корпоративному програмному забезпеченні.

Всі описані методи захисту відносяться до кінця 80-х — початку 90-х років, і не використовуються в сучасному світі.

Єдине, що актуально на сьогоднішній день — це прив'язка до унікальності заліза, а саме до моделей і серійними номерами компонентів. Як бачите, проблема захисту програмного забезпечення була досить обширною, раз було створено таку кількість методів її вирішення. Але це було ще півбіди.
Головним джерелом проблем управління ІТ-інфраструктури стало не стільки наростання обсягів і різноманіття, скільки інтенсивне розширення кількості та найменувань апаратного забезпечення. Дуже швидко персональний комп'ютер з'явився у кожного працівника компаній і підприємств, стали закуповуватися сервери, оргтехніка, периферійне обладнання. З поширенням Інтернету та мережевих технологій з'явилися додаткові проблеми. Це були завдання зовсім іншого рівня, багато з яких досі вирішуються з працею.

Корпоративний сектор потрапив в мережі: перші стандарти
Перші повноцінні мережеві рішення стали з'являтися на початку 90-х, майже відразу після розпаду СРСР. Підхід держави до економіки змінився: у минуле відійшла командна економіка, коли держава боялося, що вчені чи керівники підприємств отримають доступ до неспотвореної статистикою. До того ж, на ринок прийшли іноземні компанії-виробники комп'ютерів. З іншого боку, став розвиватися бізнес, з'явилися численні фірми — персональні комп'ютери були затребувані. Велика кількість ПК вимагало змін підходу до управління взаємодією користувачів — робочі станції потрібно було об'єднувати. Зростав попит не тільки на ПК, але і на програмне забезпечення, і на обслуговування, і на масштабні проекти, з яких виросла нинішня системна інтеграція. Першопрохідці російського мережевого ринку залишилися в історії. Можливо, хтось ще пам'ятає такі імена, як SCO Unix, Cabletron, Novell Netware, Wellfleet. Зараз їх мало хто згадає, але тоді вони несли мережеві технології в молодий російський бізнес. Трохи пізніше прийшла Cisco.


Тут треба зупинитися і сказати, що в компаніях пізнього СРСР і Росії початку 90-х використовувалися стандарти побудови мережі X. 25 і Frame relay (обидва — канальний рівень мережевої моделі OSI). X. 25 дозволяв організовувати глобальні обчислювальні мережі на основі телефонних мереж, працював з встановленням з'єднання: використовувалася зовнішня фізична середовище у вигляді цифрових каналів передачі, попарно зв'язують вузли комутації один з одним і з абонентськими терміналами за принципом точка-точка. При використанні цього стандарту частота помилок була високою, тому доводилося розробляти численні механізми корекції помилок. Однак стандарт був надійним і доступним (працював поверх телефонних мереж), тому широко використовувався в корпоративному секторі. Мережі Х. 25 здатні працювати по каналах низької якості, але з невеликою швидкістю (йдеться про десятки кілобіт в секунду). Недолік стандарту — неможливість інтерактивної роботи в режимі реального часу.

На комутації точка-точка побудований і протокол Frame relay, покликаний замінити Х. 25 і поширений і досі. Це канал E3 з максимальною швидкістю 34,368 мбіт/сек. Frame Relay спочатку був задуманий як протокол для використання в інтерфейсах ISDN і був призначений для динамічного розподілу ресурсів фізичного каналу між користувацькими процесами передачі даних. Протокол забезпечує безліч незалежних віртуальних каналів в одній лінії зв'язку, ідентифікованих в FR-мережі по ідентифікаторах підключення до з'єднання. Мережа Frame Relay є мережею з комутацією кадрів або мережею з ретрансляцією кадрів, орієнтованої на використання цифрових ліній зв'язку. Frame relay застосовувався і застосовується для побудови територіально розподілених корпоративних мереж в якості каналів для обміну даними між віддаленими локальними мережами (в корпоративних мережах) і каналів для обміну даними між локальними і територіальними (глобальними) мережами. Протокол хороший високою надійністю мережі і забезпечує передачу трафіку, чутливого до тимчасових затримок. Але Frame relay не забезпечує достовірність доставки кадрів і вимагає якісні канали зв'язку (що, втім, сьогодні в корпоративному секторі не є проблемою).

Однак умови на ринку диктували все більш нові вимоги до організації мереж: гігантськими темпами зростала нафтянка, розвивалися банки та фінансові установи, з'явилися оператори пейджингового, а трохи пізніше і стільникового зв'язку, які висували по тим часам просто космічні вимоги до управління ІТ-інфраструктурою. Всі ці компанії не могли обходитися без великої кількості ПК, надійно і швидко обмінюються даними по мережі, і без порядку в роботі ІТ-департаменту. Для багатьох це ставало питанням виживання в бізнесі.

Інтернет, локальні мережі і перші кроки ITSM в Росії
Вже в кінці 90-х — початку 2000-х управління ІТ-активами знаходить риси зарубіжних практик і в країну приходить ITSM (IT Service Management, управління ІТ-послугами), тобто в Росію ідеї управління ІТ-сервісами прийшли з запізненням на 10 років. Для цієї оцінки ми точкою відліку беремо кінець 80-х років, коли під егідою уряду Великобританії були розроблені перші томи бібліотеки кращих практик управління ІТ-інфраструктурою ITIL (IT Infrustructure Library), яка стала реакцією ІТ-спільноти на необхідність управління складною ІТ-інфраструктурою.

до Речі, про те, що було за кордоном
Середина 70-х років стала революційним, переломним моментом у світі інформаційних технологій. Винахід мікропроцесорів і створення компактних ЕОМ призвело до того, що комп'ютерні технології стали доступні великій кількості компаній, а коло завдань перестав обмежуватися обчислювальними функціями. Вже в кінці 80-х років компанії, холдинги, корпорації і державні структури зіткнулися з інтенсивним розвитком ІТ-інфраструктури. Гіганти Microsoft, IBM, HP вимагали методології управління IT-послугами. Потрібна була точка натхнення.
Як відомо, якщо немає ідей, їх потрібно шукати в інших індустріях, «красти як художник», адаптувати і впроваджувати. Так і сталося — експертів надихнув конвеєр, який став використовувати Генрі Форд в автомобілебудуванні. ІТ-індустрію влаштовували переваги: мінімізація людського фактора, скорочення рутини, автоматизація, поліпшення якості і продуктивності. За підсумками обговорення в 1989 році з'явилися перші томи бібліотеки ITIL. У 1991 організувався некомерційний форум itSMF, який став місцем обговорення та безперервного розвитку методів і практик. ITIL швидко набрала популярність і стала стандартом.

Примітка про ITIL. Нас, Alloy Software, часто запитують, чи потрібно володіти ITIL для того, щоб використовувати Alloy Navigator і Alloy Discovery. Відповідаємо однозначно: ні, не треба. Так, при розробці наших сервісів ми керувалися кращими практиками та створювали ЗА виходячи з положень ITIL, але одночасно з цим інтерфейс і логіка побудовані так, що клієнтам просто зручно використовувати софт, без знання, а часом і найменшого розуміння ITIL.
Першими зацікавленість у вивченні ITIL виявили структури Центрального Банку РФ ще в 1998 році. Саме тоді компанія Hewlett-Packard починає просувати на ринок свою методологію управління ІТ-сервісами на базі ITIL. HP знала, що робить, — у неї на той момент в портфелі були програми, які були розроблені завдяки придбанню в той час провідного розробника засобів автоматизації служб технічної підтримки та інших процесів ITIL/ITSM, голландської компанії Prolin. ITSM популяризували і впроваджували допомогою модного і донині маркетингового прийому — безкоштовних навчальних семінарів.

І навіть дефолт серпня 1998 року зіграв HP і його формуванням конкурентам на руку. Налякані представники бізнесу намагалися вижити на руїнах економіки і прагнули економити буквально на всьому. Безкоштовні семінари дозволили HP продемонструвати «товар обличчям». Підприємці уважно вивчали пропозицію до покупки й укладали угоди в атмосфері відносного спокою. Курси та семінари у навчальному центрі поступово коммерциализировались, а HP отримав свою частку на ринку російського ITSM.

Ми невипадково обмовилися про те, що стільникові компанії потребували управління ІТ-інфраструктурою. Уявіть собі: величезний оператор з масою серверів в територіально-розподілених будівлях, сотнями ПК співробітників, білінговою системою (це окрема інфраструктура всередині компанії), тоді ще тисячами і сотнями тисяч абонентів, сервісними інженерами з портативними ноутбуками. На тлі поширення внутрішньокорпоративних мереж і зовнішнього інтернету вся махина з працею управлялася і инвентаризировалась ІТ-відділом або навіть всім ІТ-департаментом. Телефони системних адміністраторів розривалися від дзвінків співробітників, терміновість і пріоритет завдань визначалися навмання, по-братськи «за пиво». Пора було з цим покінчити.

Так от, на піку буму мобільних технологій GSM і стрибка в розвитку операторів зв'язку в Росії почали широко застосовуватися практики ITSM. Це був приблизно в 2004 рік. Слідом за сотовиками в бік ITSM стали дивитися банки і фінансові корпорації. Такий попит з боку платоспроможного сектора не міг не породити пропозицію спершу консалтингових послуг, а потім і послуг автоматизації всіх процесів управління ІТ-інфраструктурою.

Підходи до організації ІТ-служби: російський менталітет і адаптований ITSM
Вже на початку 2000-х у Росії склалося два типи компаній з двома різними підходами, які досі зберігаються.

Перший — компонентний підхід. В компанії є ІТ-департамент і він надає всій іншій компанії компоненти: засоби автоматизації, програмно-апаратні комплекси, периферійні пристрої, програмне забезпечення, витратні матеріали. ІТ-служба підтримує парк техніки і виконує внутрішні заявки за запитом. До речі, стимулом до формування подібних служб в російських компаніях стало повсюдне використання коштів бухгалтерського обліку 1С: організації потрібні конфігурації і адміністрування системи, а послуги сторонніх організацій з обслуговування та налаштування бухгалтерського були занадто дорогими. Так з'явилися ІТ-служби усередині компаній, що реалізують компонентний підхід. Мінусів у такого походу не так вже й багато — в основному, все зводиться до людського чинника та проведення деяких робіт «для галочки». Незаперечний плюс — формування підконтрольної ІТ-служби всередині бізнесу, з числа співробітників, а значить, людей, які досконально знають процеси в компанії.

Другий — сервісний підхід. ІТ-служба постає повноцінної сервісною службою всередині компанії, таким внутрішнім підрядником. Професіонали в складі служби поставляють ті ж компоненти, але здійснюють повноцінний сервіс. Найчастіше взаємини з ІТ-департаментом здійснюється за допомогою тикетных систем (заявок, інцидентів). На відміну від компонентного підходу, власники бізнесу не вникають в подробиці роботи ІТ-служби, а лише вбудовують її стратегію в загальну бізнес-стратегію і процеси. Такий формалізований підхід забезпечує швидке вирішення завдань і проблем, підконтрольність ходу виконання заявок ініціатору, протоколювання взаємин. При такому підході ІТ-департамент забезпечує рівень сервісу, а значить, робота не встане з невиразним або вчасно невиправленим технічних причин. До речі, всі завдання в рамках ITSM покривають наші продукти — система повної автоматизації ІТ Alloy Navigator і система комплексного обліку і контролю програмного і апаратного забезпечення Alloy Discovery.
Саме сервісний підхід став вимагати комплексні програмні системи управління ІТ-активами, SAM (Software Asset Management, управління ліцензіями), технічної підтримки і управління інцидентами. Досвід Alloy Software показує, що такий софт затребуваний не тільки ІТ-службами.


Що отримують керівники та власники бізнесу?


  • Скорочення і прозорість витрат на ІТ — облік ліцензій та інвентаризація парку техніки дозволяють своєчасно планувати закупівлю софта і обладнання виходячи з реальних потреб. SAM (управління ліцензіями) допомагає виявляти реально програмне забезпечення і купувати/продовжувати тільки потрібні ліцензії.

  • Зниження репутаційних ризиків — керуючи активами, компанія контролює появу неліцензійного ПЗ на машинах співробітників, відповідно, уникає санкцій вендорів і простоїв у роботі до моменту усунення всіх колізій і порушень.

  • Захист комерційної таємниці та інвестицій. Встановлення неліцензійного ПЗ — це можливість впровадити в мережу віруси і трояни, що досить легко веде до втрати комерційної документації, листування, і як наслідок — втрати інвестицій. Таким чином, можна втратити технології, розробки, цінну фінансову інформацію та ін., а це величезні грошові втрати, які можуть привести до різних неприємностей, аж до ліквідації компанії.

  • Зростання загальної продуктивності — управління інцидентами та тікет-система дозволяють закривати запити внутрішнього клієнта швидко і з чітким розподілом відповідальності.

  • Безпека використання ІТ-активів — компанія надійно захищена в тому числі від розкрадання компонентів і заміни їх на менш потужні з метою «апгрейду» особистих комп'ютерів.

  • Стабільність персоналу, менше звільнень через перенапружених умов і комунікаційних проблем.

Що отримують системні адміністратори і мережеві інженери?


  • Обґрунтування ІТ-бюджетів — розмір потреб і строки заміни застарілого обладнання заздалегідь відомі, можна закласти точні потреби в рамках бюджетного планування.

  • Впорядкованість робочих процесів, протоколи дій, можливість планування діяльності сприяють ефективній і продуктивній роботі, забезпечують прозорість дій, формують відповідальність працівників ІТ-служби і виключають зайву роботу, яка виникала внаслідок хаотичності в управлінні.

  • Автоматична обробка і эскалирование заявок забезпечують грамотне управління своїм робочим процесом, скорочують терміни вивчення і вирішення проблеми.

  • Можливості аудиту і контролю за використанням програмного забезпечення, корпоративної локальної мережі і зовнішніх пристроїв. Якщо того вимагає політика компанії, можна відстежувати будь-яка зміна конфігурації терміналів користувача, виявляти і припиняти їх несанкціоноване або потенційно небезпечне використання.

  • Можливість відстежувати історію апаратного забезпечення в одному місці — коли купили, коли закінчилася гарантія, коли возили в ремонт, скільки разів возили в ремонт, які були скарги користувачів, пов'язані з цією залізякою.

  • Відстежування трендів. Наприклад, вінчестери XYZ з постачання 2013 року вже наполовину вийшли з ладу — можливо, не потрібно чекати, коли відмовлять всі і варто замінити їх превентивно.

  • Зростання продуктивності праці, швидкості обробки заявок і задоволеності користувачів. Інженерам і адміністратори не потрібно збирати подробиці інциденту і шукати спільну мову з користувачами для розуміння їх проблеми. Всі деталі можна переглянути онлайн виходячи з заявки.

  • Вимірність діяльності ІТ-служби: не потрібно нікому доводити свою продуктивність в звітному періоді, всі дані по обробленим інцидентів, питань і робота з ІТ-інфраструктурою є всередині системи моніторингу.

Що отримують працівники компанії?

  • Швидке виконання заявок — робота проходить без простоїв, людський фактор мінімізується, чуйність до вирішення проблем зростає.

  • Безпека — користувач впевнений в тому, що його і комп'ютер завжди мають актуальну версію, вірно налаштовано і потенційні проблеми втрати даних зменшуються.

  • Використання ліцензійного ПЗ гарантує збереження даних, дозволяє звертатися за підтримкою не тільки в ІТ-департамент, але і до вендора.
Звичайно, ITSM і ITIL у своїй споконвічній задумом — це не по-російськи, і російському менталітету складно прийняти їх такими, які вони є в міжнародній практиці. Однак сьогодні команда Alloy Software спостерігає стабільне зростання попиту на системи моніторингу та управління ІТ-інфраструктурою. І ми виступаємо за адаптацію ITSM до потреб російського корпоративного сектора. Головне, що є розуміння того, що це не фішка і не наворот, а об'єктивна частина бізнесу. Та сама, яка відповідає за безпеку, стабільність, безперебійну роботу і економію. Власне, воно всім і треба.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.