Перезавантаження, яке дісталося до складу
У логістичній компанії на 600 людей IT-відділ складався з чотирьох осіб. Вони вели таблицю серверів: назва, адреса, операційна система, хто відповідає. Таблиця була точна. Ніхто не пригадував, щоб вона хоч раз помилялася.
У вівторок після обіду один з інженерів перезавантажив сервер app-07, щоб поставити оновлення. У таблиці він значився як «сервер застосунків». Там не було написано, що app-07 друкує транспортні етикетки для складу, що складська система звертається до нього по етикетку щоразу, коли посилка виїжджає з рампи, і що о пів на третю біля рампи вже чекала вантажівка. Перезавантаження тривало чотири хвилини. Купу посилок без етикеток розгрібали дві години.
Нічого незвичайного в цій історії немає. Таблиця не брехала. Їй бракувало другої половини речення: app-07 це сервер застосунків, без якого склад не може працювати. У списку є рядки. А на сервіс чекають люди.
Чому списку мало
Більшість команд починає зі списку, бо це просто. Його можна вивантажити майже звідки завгодно. Він відповідає на питання «що в нас є?», і на це питання справді треба мати відповідь.
Біда в тому, що майже кожне рішення в IT стосується зв’язків, а не рядків. Чи можна перезавантажити цей сервер сьогодні ввечері? Залежить від того, що на ньому працює. Чи можна перенести цю групу адрес? Залежить від того, які сервіси ними користуються. Яка ліцензія перестане працювати, якщо видалити ту програму? Кого попередити, перш ніж система резервного копіювання зникне на годину? Жодне з цих питань не вирішиш сортуванням стовпця.
Тож відповіді зберігаються в головах. Інженерка, яка колись налаштовувала друк етикеток, знає, що app-07 важливий. Коли вона у відпустці або вже перейшла в іншу компанію, ці знання йдуть разом з нею. А таблиця виглядає точнісінько так само, як і раніше.
Запишіть увесь ланцюжок
В AverDesk сервер лише один запис серед багатьох. В обліку є й те, що насправді важить для бізнесу: продукти, сервіси всередині них, робочі копії кожного сервісу, сервери, на яких вони працюють, обладнання, адреси, програми, ліцензії, приміщення й будівлі, облікові записи, перевірки та правила резервного копіювання. У кожного запису свої поля, своя історія змін і свої зв’язки з іншими. (Для IT-читача: продукти, сервіси, екземпляри сервісів, хости, обладнання, IP-адреси, підмережі, ПЗ, ліцензії, локації, облікові записи, монітори та вимоги до резервного копіювання.)
Для друку етикеток ланцюжок такий. Продукт «Складські операції». У ньому сервіс «Друк етикеток». У сервісу одна робоча копія, і вона працює на сервері app-07, а той стоїть на конкретній фізичній машині, у конкретній стійці, у конкретній будівлі. У записі сервісу також указано, які порти він займає, із якою зовнішньою системою друку спілкується і де лежить його запасна копія на випадок, якщо основна впаде.
Коли ланцюжок є, на питання «чи можна перезавантажити app-07?» з’являється відповідь, яку видно на власні очі. Відкриваєте сервер і бачите, що над ним. Перегляд залежностей іде ланцюжком угору: сервер, далі робоча копія, сервіс, продукт і люди, які ним користуються. Вирішувати про перезавантаження все одно вам. Просто воно вже не стане сюрпризом.
Зв’язки за правилами
Така карта корисна, доки в ній порядок, тому AverDesk ставить зв’язкам обмеження. Кожна організація сама визначає, які типи зв’язків дозволені і скільки зв’язків кожного типу може мати об’єкт. Замкнені кола заборонені: якщо хтось спробує зробити так, щоб сервіс через три кроки залежав сам від себе, система відхилить зв’язок і покаже шлях, який замкнув би коло.
Деякі поля передаються ланцюжком униз. Робоча копія може взяти розташування чи правило резервного копіювання від сервісу над нею, тож ніхто не вводить одне й те саме двічі. Коли два «батьки» кажуть різне, ніхто не вгадує. AverDesk показує конфлікт, і правильне значення обирає людина. Кожне поле зберігає історію: видно, хто змінив відповідального за сервер, коли і що там було до того.
Ми називаємо це живою документацією. Вам не треба писати окрему сторінку про друк етикеток, а потім забувати її оновлювати. Запис сервісу з його серверами, портами, зовнішніми підключеннями та запасним майданчиком і є документацією, і він змінюється разом зі справжнім сервісом.
Знайдіть те, що ніхто не пов’язав
Є й тихіша проблема: речі, які є в обліку, але ні з чим не пов’язані. Тестовий сервер, який забули видалити. Ліцензія, яку ніхто не прив’язав до програми. Група адрес, яка використовується, але жоден сервіс на неї не претендує.
AverDesk шукає такі речі навмисно. Карта інфраструктури підсвічує об’єкти без зв’язків і об’єкти, чиї зв’язки так і не ведуть до жодного продукту. Зазвичай це означає, що ніхто не знає, навіщо вони. Щоденна перевірка повідомляє про все, що знову «загубилося», щоб купа сиріт не росла тихенько рік, поки хтось не помітить.
З чого почати
Не треба описувати все IT в перший же день. Візьміть один сервіс, зупинка якого заболить: таке, що склад, цех чи відділ продажів помітять протягом години. Запишіть його продукт, сервіс, робочі копії та сервери. Додайте людей, які за нього відповідають. Це робота на одне пообіддя. Наступного разу, коли хтось відкриє цей сервер перед перезавантаженням, він побачить, що за ним стоїть склад.
Якщо хочете спробувати на своїй інфраструктурі, почніть із плану Free. Одна організація, один оператор, без картки, а ще демо-організація, яку можна ламати без наслідків.
Почати безкоштовно
IT-інвентаризація, пов’язані сервіси та щоденна підтримка.
Читайте далі
Почніть з однієї послуги
Найшвидший спосіб провалити облік: імпортувати все першого ж дня. Розповідаємо, як почати з однієї послуги і рости від того, що вже працює.
· 4 хв читання
Що таке AverDesk і кому він потрібен
Простий опис продукту: список усього, що працює у вашій компанії, карта того, що від чого залежить, і служба підтримки, все в одному місці.
· 1 хв читання