Пілотный проект

Працюючи в одній із компаній, я зіткнувся з терміном "пілотний проект".

При цьому в жодній документації (стандартах чи політиках) не було цього поняття. Та й ніхто до ладу роз'яснити його не міг. Менеджери з продажу партнерів чи дистриб'юторів активно пропонували провести пілот їхніх рішень "за безкоштовно".

Тільки як проводити те, чого немає у документації? Воно поза правилами і навіщо ті правила свідомо порушувати?

Тестове середовище, виробниче середовище, середовище розробки були.
Тобто, були тестовий проект та впровадження/розгортання рішення у виробничому середовищі або у середовищі розробки.

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

При цьому залишається питання: обмежена кількість користувачів або пристроїв - це скільки? 10 - це багато чи мало? А 50? Це багато чи ще мало? Результати, які будуть отримані на такій кількості, будуть адекватними для цього конкретного виробничого середовища підприємства?

Для того, щоб не було таких слизьких моментів, потрібно вчитися, вчитися і ще раз вчитися. А краще насамперед читати документацію передових вендорів 🙂

Компанія Microsoft, наприклад, ділить проекти в ІТ-інфраструктурі на кола розгортання.

Підхід на основі кола – це метод визначення набору кінцевих точок для підключення та перевірки відповідності певним критеріям перед розгортанням служби / рішення на великому наборі пристроїв.

Для продукту Microsoft Defender це виглядає так:

Коло розгортання	Опис
Оцінка	Коло 1. Визначте 50 пристроїв для підключення до служби для тестування.
Пілотний проект	Коло 2. Визначення та підключення наступних 50–100 кінцевих точок у робочому середовищі. Microsoft Defender для кінцевої точки підтримує різні кінцеві точки, які можна підключити до служби. Для отримання додаткових відомостей див. у розділі Вибір способу розгортання.
Повне розгортання	Коло 3. Розгортання служби в іншому середовищі з великим кроком. Для отримання додаткових відомостей див. у статті Початок роботи з розгортанням Microsoft Defender для кінцевої точки.

Джерело:
https://learn.microsoft.com/ru-ru/microsoft-365/security/defender-endpoint/onboarding?view=o365-worldwide#deploy-using-a-ring-based-approach

Іншими словами, оцінка – це тестовий проект.
Повне розгортання - це рішення, яке працює у робочому виробничому середовищі.
Отже, приходимо і до наступного:

Пілотний проект / пілот – це можливість використання 50-100 одиниць обладнання у виробничому середовищі підприємства.

Користуємося!
 

💻 На стартову сторінку

 

Архітектура на прикладі Microsoft Defender for Endpoint

Архітектура - це, перш за все, малюнок, який чітко і зрозуміло (однозначно) пояснює схему рішення на всіх рівнях ІТ-інфраструктури та взаємодію всіх компонентів.
 
Декілька прикладів опису архітектури для Microsoft Defender for Endpoint:

Архітектура	опис
Хмарна архітектура	Ми рекомендуємо використовувати Microsoft Intune для підключення, налаштування та виправлення кінцевих точок із хмари для підприємств, які не мають локального рішення для керування конфігурацією або хочуть скоротити свою локальну інфраструктуру.
Співуправління	Організаціям, які розміщують як локальні, так і хмарні робочі навантаження, ми рекомендуємо використовувати ConfigMgr і Intune від Microsoft для потреб керування. Ці інструменти надають комплексний набір функцій керування на базі хмарних технологій, а також унікальні параметри спільного керування для надання, розгортання, керування та захисту кінцевих точок і додатків у всій організації.
Локальне середовище	Підприємствам, які хочуть скористатися перевагами хмарних можливостей Microsoft Defender for Endpoint, а також максимально збільшити свої інвестиції в Configuration Manager або Active Directory Domain Services, ми рекомендуємо цю архітектуру.
Оцінка та підключення вручну	Ми рекомендуємо цю архітектуру для SOC (центрів безпеки), які хочуть оцінити або запустити пілотний пакет Microsoft Defender for Endpoint, але не мають інструментів керування чи розгортання. Цю архітектуру також можна використовувати для підключення пристроїв у невеликих середовищах без інфраструктури керування, наприклад у DMZ (демілітаризованій зоні).

Як виглядає архітектура рішення залежно від різних засобів та методів підключення пристроїв до ІТ-інфраструктури.

Малюнок 1. Хмарна архітектура

Малюнок 2. Архітектура співуправління

Малюнок 3. Архітектура локального середовища

Малюнок 4. Оцінка та підключення вручну

 
Джерело:
https://learn.microsoft.com/uk-ua/microsoft-365/security/defender-endpoint/deployment-strategy?view=o365-worldwide#step-1-identify-your-architecture