Мапа технічних навичок
IT-менеджера.

Клієнт (браузер, мобільний застосунок) надсилає запит, сервер обробляє його і повертає відповідь. Як у ресторані: ви робите замовлення офіціанту, а кухня, якої ви не бачите, його готує.

Навіщо це менеджеру

Коли ви розумієте, де живуть логіка і дані, ви правильно читаєте оцінки: «поправити на клієнті» і «змінити на сервері» відрізняються за строками, ризиками і тим, чи потрібен реліз в App Store або Google Play.

Де знадобиться

• Мобільний застосунок з особистим кабінетом
• Вебсервіс для запису до лікаря
• Онлайн-гра з рейтингом гравців
• Термінал самообслуговування з центральним обліком

Як це звучить у команді

• «Це ламається на клієнті, сервер тут ні до чого»
• «Сервер ліг, тому застосунок не вантажиться»
• «Логіку винесемо на бекенд»

Що спитати в команди

Що в нашому продукті виконується на пристрої користувача, а що на сервері, і що побачить користувач, якщо сервер тимчасово недоступний?

Стартова тема: попередніх знань не потрібно.

Відкриває далі: HTTP та HTTPS, API, Frontend, Backend і Fullstack, Сервери, VPS і хостинг, Мережі: як комп’ютери спілкуються

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

HTTP — це правила, за якими браузер і сервер обмінюються запитами й відповідями; HTTPS робить те саме, але з шифруванням. Кожна відповідь має код стану: 200 «усе гаразд», 404 «не знайдено», 500 «сервер зламався».

Навіщо це менеджеру

Коди відповідей — найшвидший спосіб зрозуміти, чия помилка: 4xx зазвичай на боці того, хто запитує, 5xx на боці сервера. Сайт без HTTPS браузер позначає як «Не захищено», геолокація й оплата на ньому не працюють: це блокер запуску, а не «дрібниця на потім».

Де знадобиться

• Публічний сайт компанії з формами заявок
• Платіжна сторінка з введенням картки
• Інтеграція з державними реєстрами
• Лендинг з A/B-тестами та аналітикою

Як це звучить у команді

• «Повертає 404, такого ендпоінта не існує»
• «Сертифікат протух, браузер лається»
• «Треба зробити редирект з http на https»

Що спитати в команди

Чи всі наші домени й піддомени працюють тільки через HTTPS, і хто стежить за поновленням сертифікатів?

Спершу варто знати: Клієнт-серверна архітектура

Відкриває далі: REST API, Балансування навантаження, CDN, Кешування: Redis та інші, WebSockets та realtime, SSL/TLS: як працює HTTPS, Автентифікація та авторизація: OAuth, SSO, JWT

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

API — це «меню» програми: перелік запитів, які їй можна надіслати (кожна така адреса — ендпоінт), і відповідей, які вона поверне. Через API ваш продукт приймає оплату, отримує погоду, надсилає push-сповіщення або віддає дані партнерам.

Навіщо це менеджеру

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

Де знадобиться

• Сервіс доставки з відстеженням кур’єра
• Застосунок банку з push-сповіщеннями
• Інтеграція CRM з поштовою розсилкою
• B2B-платформа, що віддає дані партнерам

Як це звучить у команді

• «Ендпоінт ще пишеться, фронт працює на заглушках»
• «Партнер змінив контракт без попередження»
• «Впираємось у їхній rate limit»

Що спитати в команди

Які зовнішні API критичні для продукту, і що побачить користувач, якщо одне з них перестане відповідати?

Спершу варто знати: Клієнт-серверна архітектура

Відкриває далі: JSON, REST API, SDK, бібліотеки та сторонні інтеграції, Cloud-функції та serverless, Черги повідомлень та асинхронність, Моноліт vs мікросервіси, Технічні вимоги та acceptance criteria, Автентифікація та авторизація: OAuth, SSO, JWT

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

JSON — текстовий формат, у якому програми передають дані: поля й значення у фігурних дужках, зрозумілі і людині, і машині. Саме в JSON приходить відповідь майже кожного сучасного API.

Навіщо це менеджеру

Уміння прочитати JSON у логах чи в інструменті для тестування API на кшталт Postman дає змогу самостійно побачити, що саме повернув сервер, і не чекати на розробника. А домовленість про поля (число це чи рядок) рятує від сюрпризів під час інтеграції.

Де знадобиться

• Прайс-лист, який постачальник віддає через API
• Чат-бот у Telegram чи Viber
• Синхронізація замовлень із ERP-системою
• Експорт даних для партнерів файлом

Як це звучить у команді

• «Поле прийшло як null, тому й падає»
• «Бекенд віддає ціну рядком, а не числом»
• «Скинь мені відповідь у JSON»

Що спитати в команди

Чи зафіксовано, які поля обов’язкові у відповіді, і що зробить наш застосунок, якщо якогось поля не буде або воно прийде порожнім?

Спершу варто знати: API

Відкриває далі: REST API

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

Фронтенд — усе, що користувач бачить і на що натискає; бекенд відповідає за логіку, дані й розрахунки на сервері. Fullstack-розробник працює з обома частинами, але зазвичай має сильнішу сторону.

Навіщо це менеджеру

Без узгодженого контракту API (які запити й відповіді) фронтенд і бекенд блокують одне одного: екран можна почати на заглушках, тимчасових фіктивних відповідях, але не довести до кінця. Узгодьте контракт першим, і команда працюватиме паралельно.

Де знадобиться

• Кабінет клієнта страхової компанії
• Адмінпанель для операторів кол-центру
• Онлайн-курси з відео та тестами
• Сервіс бронювання столиків у ресторанах

Як це звучить у команді

• «Фронт готовий, чекаємо на бекенд»
• «Це верстка, бекендер тут не потрібен»
• «Візьмемо fullstack, щоб закрити обидві частини»

Що спитати в команди

Що з цієї фічі робить фронтенд, що бекенд, і чи узгоджено між ними контракт API до старту розробки?

Спершу варто знати: Клієнт-серверна архітектура

Відкриває далі: Мови програмування та фреймворки

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

Мова програмування — це те, чим пишуть код (JavaScript, Python, Java, Go, Swift). Фреймворк або бібліотека для цієї мови дає готовий каркас, який задає структуру й економить час (React, Django, Spring).

Навіщо це менеджеру

Вибір стека (набору мов і фреймворків) визначає, кого і за скільки ви зможете найняти, чи знайдете підрядника на підтримку і чи не залишитесь із проєктом, який ніхто не хоче супроводжувати. Немає «найкращої мови», є доречна для завдання й ринку.

Де знадобиться

• Стартап, що обирає стек з нуля
• Legacy-система мовою, з якої всі пішли
• Мобільний застосунок: нативний чи кросплатформний
• Аутсорс-проєкт з передачею коду замовнику

Як це звучить у команді

• «Це на React, а бекенд на Node»
• «Фреймворк давно не оновлювали, версія стара»
• «Під цей стек важко знайти людей»

Що спитати в команди

Чому обрано саме цей стек, чи актуальні версії фреймворків, і наскільки легко знайти на ринку людей на його підтримку?

Спершу варто знати: Frontend, Backend і Fullstack

Відкриває далі: SDK, бібліотеки та сторонні інтеграції

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

Git — це система, яка зберігає повну історію змін коду: хто, коли і що змінив, з можливістю повернутися до будь-якої версії. Схоже на «Історію версій» у Google Docs, тільки для всього проєкту й з паралельними гілками під різні задачі.

Навіщо це менеджеру

Git показує реальний стан роботи: що вже злито в основну гілку, а що досі чекає на перевірку й злиття в pull request на GitHub чи GitLab. Помилка вважати, що «закомічено» означає «готово»: до проду код ще має пройти перевірку, злиття і розгортання.

Де знадобиться

• Команда з трьох і більше розробників над одним продуктом
• Аутсорс, де код має належати клієнту
• Проєкт із хотфіксами на старій версії
• Передача проєкту від одного підрядника іншому

Як це звучить у команді

• «Я ще не запушив»
• «Підтягни main, там конфлікт»
• «Відкотимо на попередній коміт»

Що спитати в команди

Чи весь код проєкту лежить у репозиторії, який контролюємо ми, і чи можемо ми будь-якої миті повернути будь-яку попередню версію?

Стартова тема: попередніх знань не потрібно.

Відкриває далі: Середовища: dev, stage, prod, Code review та якість коду, CI/CD

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

Середовища — це окремі копії системи для різних цілей: dev для розробки, stage для перевірки перед випуском, prod для реальних клієнтів. Як репетиція, генеральний прогін і прем’єра в театрі.

Навіщо це менеджеру

Без stage кожна демонстрація клієнту і кожен реліз відбуваються «наживо», з ризиком зламати роботу користувачів. Знаючи, де саме показують фічу, ви не переплутаєте тестові дані з реальними і не пообіцяєте те, що ще не на проді.

Де знадобиться

• SaaS із щотижневими релізами для клієнтів
• Демо нової версії замовнику перед прийманням
• Інтеграція з платіжним провайдером у тестовому режимі
• Мобільний застосунок з окремим бекендом для QA

Як це звучить у команді

• «На стейджі працює, на проді ні»
• «Це задеплоєно тільки на dev»
• «Хто зараз зайняв stage?»

Що спитати в команди

Скільки в нас середовищ, наскільки stage відрізняється від prod за даними й конфігурацією, і хто вирішує, коли зміни їдуть далі?

Спершу варто знати: Git і версіювання коду

Відкриває далі: Тестування: unit, integration, e2e, Release-стратегії, CI/CD, Docker і контейнери, Моніторинг та метрики, Секрети, ключі та керування доступами

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

Сервер — це комп’ютер, який працює без вихідних і віддає ваш сайт чи застосунок усім, хто до нього звертається. Хостинг — оренда такого комп’ютера або його частини (VPS) у провайдера замість купівлі власного «заліза».

Навіщо це менеджеру

Від хостингу залежать бюджет, швидкість для користувачів і те, хто відповідає за оновлення та безпеку. Розуміючи різницю між спільним хостингом (shared), VPS і виділеним сервером (dedicated), ви не переплатите і не отримаєте «сервер упав» у день запуску.

Де знадобиться

• Корпоративний сайт із формою заявки
• Невеликий інтернет-магазин на CMS
• Внутрішня база знань компанії
• MVP стартапу на одному сервері

Як це звучить у команді

• «Треба орендувати VPS на 4 гігабайти»
• «У нас закінчується місце на диску»
• «Сервер лежить, чекаємо провайдера»

Що спитати в команди

Де саме працює наш продукт, хто має доступ до сервера і що станеться, якщо він вийде з ладу сьогодні ввечері?

Спершу варто знати: Клієнт-серверна архітектура

Відкриває далі: Хмара vs on-premise: AWS, GCP, Azure, Docker і контейнери, Балансування навантаження, Віртуальні машини, SSH та доступ до серверів

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

Реляційна база даних зберігає дані в таблицях зі зв’язками між ними, як набір пов’язаних Excel-аркушів: клієнти, замовлення, товари. SQL — мова, якою дані в цих таблицях читають і змінюють.

Навіщо це менеджеру

Майже кожен продукт зберігає гроші, замовлення й користувачів саме тут. Розуміння структури даних пояснює, чому «додати одне поле» іноді займає тиждень і які дані реально можна показати клієнту.

Де знадобиться

• CRM з клієнтами, угодами та історією контактів
• Облік замовлень в інтернет-магазині
• Система бронювання квитків
• ERP для складу та бухгалтерії

Як це звучить у команді

• «Треба додати таблицю і написати міграцію»
• «Це один SELECT з JOIN»
• «Схема бази під таку зміну не розрахована»

Що спитати в команди

Яка в нас схема даних для цієї функції і чи потрібна зміна структури бази (міграція схеми), яка вплине на строки або вимагатиме простою?

Стартова тема: попередніх знань не потрібно.

Відкриває далі: Кешування: Redis та інші, Типові архітектури проєктів, NoSQL: документні та key-value бази, Бекапи та відновлення даних, Індекси та продуктивність запитів, Транзакції та ACID, Реплікація та read-репліки, ETL та Data Pipeline

Розібрати на інтенсиві: модуль 3 «Бази даних та їх особливості» ↗

Технічна документація — це письмова пам’ять проєкту: як система влаштована, як її запустити, які рішення ухвалено і чому. Це README, wiki, інструкції з розгортання та описи модулів. Без неї знання живуть лише в головах розробників.

Навіщо це менеджеру

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

Де знадобиться

• Передача проєкту від аутсорсу внутрішній команді
• Онбординг розробників у команду, що росте
• Legacy-система, яку знає одна людина
• Стартап після виходу засновника-CTO

Як це звучить у команді

• «Це є в README, але він застарів»
• «Спитай у Сашка, він це писав»
• «Треба оновити wiki після релізу»

Що спитати в команди

Чи зможе новий розробник за документацією самостійно розгорнути проєкт локально, і коли її востаннє оновлювали?

Стартова тема: попередніх знань не потрібно.

Відкриває далі: Технічні вимоги та acceptance criteria, API-документація: OpenAPI, Swagger, Postman, Архітектурні діаграми: C4, Lucidchart, draw.io, ADR та RFC: фіксація технічних рішень

Розібрати на інтенсиві: модуль 5 «Документація» ↗

Мережа — це спосіб, яким комп’ютери передають дані один одному: ваш ноутбук, Wi-Fi-роутер, провайдер, десятки проміжних вузлів і нарешті сервер. Кожне повідомлення ріжеться на пакети, що йдуть різними шляхами, як листи через пошту.

Навіщо це менеджеру

Коли «сайт не працює», проблема може бути на будь-якій ділянці шляху, а не лише у вашому коді. Розуміння маршруту допомагає не звинувачувати команду передчасно і поставити правильне питання: де саме обривається?

Де знадобиться

• Офісна мережа з доступом до внутрішніх систем
• IoT-пристрої, що передають дані на сервер
• Роздрібна мережа з касами, підключеними до сервера
• Сервіс, що працює за нестабільного зв’язку

Як це звучить у команді

• «Пакети губляться десь по дорозі»
• «Це проблема на боці провайдера»
• «Сервер не бачить базу по мережі»

Що спитати в команди

Коли користувач скаржиться, що «не працює», як ми з’ясовуємо, де саме обривається шлях: у нього, у провайдера чи в нас?

Спершу варто знати: Клієнт-серверна архітектура

Відкриває далі: IP-адреси та порти, Latency та bandwidth: чому «гальмує», Типи кібератак: DDoS, фішинг, ін’єкції

Розібрати на інтенсиві: модуль 6 «Мережева комунікація» ↗

IP-адреса — це номер комп’ютера в мережі, як адреса будинку. Порт — номер «дверей» на цьому комп’ютері: 443 для HTTPS, 5432 для PostgreSQL. Пакет знаходить сервер за IP, а потрібну програму на ньому за портом.

Навіщо це менеджеру

Чимало проблем «після переїзду на новий сервер нічого не працює» зводяться до закритого порту або зміненої адреси. Знаючи це, ви зрозумієте, чому доступ до бази з офісу потребує окремого рішення, а не просто «відкрити».

Де знадобиться

• Переїзд сервісу на новий сервер або хостинг
• Інтеграція з банком через список дозволених IP
• Підключення філії до внутрішнього сервера
• Налаштування доступу підрядника до бази

Як це звучить у команді

• «Порт закритий фаєрволом»
• «Треба додати наш IP у їхній whitelist»
• «У нас статичний IP чи динамічний?»

Що спитати в команди

Які порти у нас відкриті назовні, хто це контролює і чи є список IP-адрес, з яких дозволено доступ до бази?

Спершу варто знати: Мережі: як комп’ютери спілкуються

Відкриває далі: DNS та домени, TCP та UDP, Proxy, reverse proxy та VPN

Розібрати на інтенсиві: модуль 6 «Мережева комунікація» ↗

DNS — телефонна книга інтернету: перетворює зрозуміле людям ім’я (redcamp.pro) на IP-адресу сервера. Домен ви орендуєте в реєстратора, а DNS-записи кажуть, куди саме вести сайт, пошту й піддомени.

Навіщо це менеджеру

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

Де знадобиться

• Запуск нового бренду з власним доменом
• Міграція сайту на інший хостинг без простою
• Корпоративна пошта на власному домені
• Окремий піддомен для кожного клієнта в SaaS

Як це звучить у команді

• «DNS ще не оновився, зачекайте пару годин»
• «Треба додати A-запис і CNAME»
• «Домен зареєстровано на колишнього підрядника»

Що спитати в команди

На кого зареєстровано наш домен, хто має доступ до DNS-записів і коли закінчується оплата?

Спершу варто знати: IP-адреси та порти

Відкриває далі: CDN, Proxy, reverse proxy та VPN

Розібрати на інтенсиві: модуль 6 «Мережева комунікація» ↗

Безпека в IT — це відповідь на три питання: що саме ми захищаємо (дані клієнтів, гроші, репутацію), від кого (зловмисники, конкуренти, недбалі співробітники) і якою ціною. Як замок на дверях: його вибирають під те, що всередині.

Навіщо це менеджеру

Найшкідливіший міф: «нас ніхто не атакує, ми маленькі», хоча автоматизовані боти сканують усе підряд. Розуміючи модель загроз (відповіді на ті самі три питання), ви обґрунтуєте клієнту бюджет на безпеку і не пропустите ризик, який зупинить реліз.

Де знадобиться

• Стартап, що збирає персональні дані користувачів
• Корпоративний портал з даними співробітників
• Тендерний проєкт для держустанови
• Аутсорс-контракт з вимогами безпеки від клієнта

Як це звучить у команді

• «Яка в нас модель загроз?»
• «Це треба погодити із security-командою»
• «У цього ризику немає власника»

Що спитати в команди

Які дані в нашому продукті найцінніші для зловмисника, і хто в команді відповідає за їхній захист?

Стартова тема: попередніх знань не потрібно.

Відкриває далі: SSL/TLS: як працює HTTPS, Типи кібератак: DDoS, фішинг, ін’єкції, Комплаєнс та аудит: GDPR, PCI DSS, SOC 2

Розібрати на інтенсиві: модуль 7 «Безпека даних та інфраструктури в IT» ↗

REST — найпоширеніший стиль побудови API поверх HTTP: кожна сутність (замовлення, користувач) має свою адресу, а дії описують методами GET (отримати), POST (створити), PUT/PATCH (змінити), DELETE (видалити).

Навіщо це менеджеру

Передбачуваний REST API дешевше інтегрувати. Видалення, перейменування чи зміна типу поля без нової версії ламає застосунки в користувачів, які не оновились (додати необов’язкове поле зазвичай безпечно), тому версіювання API є і вашим питанням як менеджера.

Де знадобиться

• Публічне API для партнерів та агрегаторів
• Мобільний застосунок і вебверсія на спільному бекенді
• Маркетплейс з інтеграцією продавців
• Внутрішнє API, яким користуються кілька команд

Як це звучить у команді

• «Зробимо GET /orders/{id}»
• «Відповідь не збігається з контрактом»
• «Виводимо v2 і ще пів року тримаємо v1»

Що спитати в команди

Як ми версіюємо API і скільки часу підтримуємо стару версію після виходу нової, щоб не зламати клієнтів, які не оновились?

Спершу варто знати: API, HTTP та HTTPS, JSON

Відкриває далі: API-документація: OpenAPI, Swagger, Postman

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

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

Навіщо це менеджеру

Кожна зовнішня залежність — це чужий реліз-цикл, ліцензія та ризик, що її перестануть підтримувати або зроблять платною. Оцінюючи фічу на готовому SDK, закладіть час на оновлення й запасний план, а не лише «підключили за день».

Де знадобиться

• Онлайн-оплата картками та Apple Pay
• Застосунок з картами та геолокацією
• Продукт із входом через Google чи Apple ID
• Сервіс із push-сповіщеннями та продуктовою аналітикою

Як це звучить у команді

• «Підключимо готову бібліотеку, не пишемо своє»
• «Їхній SDK зламав збірку після оновлення»
• «Ця ліцензія не дозволяє комерційне використання»

Що спитати в команди

Від яких сторонніх SDK і бібліотек залежить продукт, хто стежить за їхніми оновленнями й безпекою, і що буде, якщо одну з них перестануть підтримувати?

Спершу варто знати: API, Мови програмування та фреймворки

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

Автоматичні тести перевіряють код без участі людини: unit-тести дивляться на окремі функції, integration-тести на взаємодію модулів і бази даних, e2e проходять сценарій користувача цілком. Разом це «піраміда»: багато швидких дрібних, мало повільних наскрізних.

Навіщо це менеджеру

Тести — це страховка від регресій: без них кожна нова фіча ризикує зламати стару, а час ручного QA росте з кожним релізом. Помилка вважати, що «покриття 80%» гарантує якість: важливо, що саме перевіряють тести, а не відсоток.

Де знадобиться

• Біллінг із розрахунком тарифів і знижок
• Довгостроковий продукт із щоденними змінами
• Legacy-система, яку страшно чіпати
• Застосунок із критичним сценарієм оформлення замовлення

Як це звучить у команді

• «Тести впали на CI»
• «Це не покрито тестами»
• «E2E флакі: падають через раз, перезапустимо»

Що спитати в команди

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

Спершу варто знати: Середовища: dev, stage, prod

Відкриває далі: CI/CD, Навантажувальне тестування

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

Code review — це перевірка коду колегою до того, як він потрапить в основну гілку, зазвичай через pull request (у GitLab це merge request). Як редактор вичитує статтю перед публікацією, так і рев’юер ловить помилки, незрозумілі рішення й відхилення від домовленостей команди.

Навіщо це менеджеру

Рев’ю додає час до задачі, зате зменшує кількість багів на проді й поширює знання в команді: без нього код розуміє лише автор. Якщо pull request чекають днями, це вузьке місце доставки, яке краще побачити раніше, ніж зірветься реліз.

Де знадобиться

• Команда з джуніорами, яких треба ростити
• Фінтех із вимогами аудиту змін у коді
• Продукт, де один розробник знає весь код
• Аутсорс-команда, що здає код замовнику

Як це звучить у команді

• «Мій PR висить третій день»
• «Апрувну після правок»
• «Лінтер не пропускає»

Що спитати в команди

Скільки в середньому pull request чекає на рев’ю, і чи є в системі частина, яку розуміє лише одна людина?

Спершу варто знати: Git і версіювання коду

Відкриває далі: Технічний борг, ADR та RFC: фіксація технічних рішень, OWASP Top 10 та захист вебзастосунків

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

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

Навіщо це менеджеру

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

Де знадобиться

• MVP, який раптом став основним продуктом
• Стартап після раунду, що масштабує команду
• Продукт після кількох змін підрядника
• Успадкована система на застарілому фреймворку

Як це звучить у команді

• «Тут треба рефакторити, інакше не зробимо»
• «Це костиль, ми знали»
• «Бібліотека вже не підтримується»

Що спитати в команди

Де в нас зафіксовано технічний борг, які пункти найбільше сповільнюють розробку, і яку частку спринту ми готові віддавати на його повернення?

Спершу варто знати: Code review та якість коду

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

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

Навіщо це менеджеру

Нечасті великі релізи здаються безпечнішими, але насправді ризикованіші: більше змін, важче знайти причину збою. Розуміючи стратегію, ви реалістично плануєте дати для клієнта та маркетингу і знаєте, що робити в разі відкату.

Де знадобиться

• Мобільний застосунок з модерацією в App Store
• Корпоративна система з релізами раз на квартал
• Вебсервіс, де клієнти чекають фікс сьогодні
• Запуск, узгоджений з маркетинговою кампанією

Як це звучить у команді

• «Заморожуємо код у четвер»
• «Хотфікс поза чергою»
• «Це піде в наступний реліз»

Що спитати в команди

Як часто ми випускаємо релізи, хто дає фінальне «так», і скільки часу займає відкат, якщо після релізу щось зламалось?

Спершу варто знати: Середовища: dev, stage, prod

Відкриває далі: Feature flags та поступовий rollout, Blue-green, canary та rolling deploy

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

CI/CD — це автоматичний конвеєр: після кожної зміни в Git система сама збирає код, проганяє тести (CI) і готує зміни до розгортання або сама розгортає їх на середовища (CD). На прод при цьому пускає або автомат, або людина кнопкою — це окреме рішення команди.

Навіщо це менеджеру

Без CI/CD кожен реліз залежить від конкретної людини і її пам’яті, а проміжок між «готово» і «на проді» непередбачуваний. Налаштований конвеєр скорочує цей проміжок і робить частоту релізів вашим управлінським рішенням, а не подвигом.

Де знадобиться

• Продукт із кількома релізами на день
• Розподілена команда в різних часових поясах
• Проєкт, де розгортати вмів лише один інженер
• Мікросервіси з десятками окремих розгортань

Як це звучить у команді

• «Пайплайн червоний»
• «Білд упав на етапі тестів»
• «Автодеплой на stage після мержу»

Що спитати в команди

Що саме відбувається автоматично від злиття pull request до появи змін на проді, і де в цьому ланцюжку досі потрібна людина?

Спершу варто знати: Git і версіювання коду, Тестування: unit, integration, e2e, Середовища: dev, stage, prod

Відкриває далі: Feature flags та поступовий rollout, DevOps як практика, Infrastructure as Code, Blue-green, canary та rolling deploy, Секрети, ключі та керування доступами

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

Хмара — оренда серверів, баз і сервісів у AWS, Google Cloud чи Azure з оплатою за фактичне використання. On-premise — власне «залізо» у своєму дата-центрі чи серверній (або colocation: свої сервери в орендованій стійці чужого дата-центру), за яке повністю відповідаєте ви.

Навіщо це менеджеру

Хмара не дешевша сама по собі: вона економить на старті й за змінного навантаження, але рахунок може рости непомітно. Розуміння моделі допомагає обрати, де запускати проєкт, і пояснити клієнту вимоги до розміщення даних.

Де знадобиться

• Сервіс із сезонними піками навантаження
• Продукт для ЄС із вимогами до розміщення даних
• Банківська система з власним дата-центром
• Стартап без бюджету на власне «залізо»

Як це звучить у команді

• «Піднімемо це в AWS за годину»
• «Рахунок за хмару виріс удвічі»
• «Клієнт вимагає on-premise»

Що спитати в команди

Чому ми обрали саме цю хмару чи власні сервери, і скільки коштуватиме переїзд, якщо умови або ціни зміняться?

Спершу варто знати: Сервери, VPS і хостинг

Відкриває далі: Cloud-функції та serverless, Типові архітектури проєктів, Вартість інфраструктури (FinOps), Infrastructure as Code

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

NoSQL — бази даних без жорстких таблиць і суворої схеми. Документні (наприклад, MongoDB) зберігають записи як JSON-документи, а key-value (Redis, DynamoDB) — як пари «ключ і значення».

Навіщо це менеджеру

Поширена помилка: обрати NoSQL «бо модно і швидко», а потім боротися з неузгодженими даними та складними звітами. Ваше питання: чи справді дані не вкладаються в таблиці, чи команда просто не хоче проєктувати схему.

Де знадобиться

• Каталог товарів з різними атрибутами в кожній категорії
• Профілі користувачів у соцмережі
• Кошик і сесії користувачів
• Збір подій з IoT-пристроїв

Як це звучить у команді

• «Схема гнучка, просто додамо поле в документ»
• «Це краще покласти в Mongo, а не в Postgres»
• «Дані розійшлися між колекціями»

Що спитати в команди

Чому для цих даних обрано NoSQL замість реляційної бази і як ми будемо будувати звіти та підтримувати узгодженість даних?

Спершу варто знати: Реляційні бази даних та SQL

Відкриває далі: ETL та Data Pipeline

Розібрати на інтенсиві: модуль 3 «Бази даних та їх особливості» ↗

Бекап — копія бази, з якої можна відновити дані після збою, помилки або атаки. Як страховка: важливо не те, що вона є, а те, що з неї реально можна відновити дані за потрібний час.

Навіщо це менеджеру

Найнебезпечніша ілюзія: «бекапи налаштовані» без жодного тестового відновлення. Вам потрібні два числа: скільки даних ми втратимо (RPO) і скільки часу займе відновлення (RTO), і їх треба погодити з клієнтом.

Де знадобиться

• Медична система з історіями пацієнтів
• Бухгалтерський SaaS для малого бізнесу
• Онлайн-курси з прогресом студентів
• Переїзд бази на новий сервер

Як це звучить у команді

• «Останній бекап був учора вночі»
• «Відновлення займе години зо три»
• «Ми ніколи не пробували розгорнутися з бекапу»

Що спитати в команди

Коли ми востаннє відновлювали базу з бекапу на тестовому середовищі і скільки даних та часу втратимо в разі збою?

Спершу варто знати: Реляційні бази даних та SQL

Відкриває далі: Відмовостійкість та disaster recovery, Комплаєнс та аудит: GDPR, PCI DSS, SOC 2

Розібрати на інтенсиві: модуль 3 «Бази даних та їх особливості» ↗

DevOps — це спосіб роботи, коли розробка та експлуатація не перекидають одна одній «м’яч через паркан», а разом відповідають за те, щоб код швидко й безпечно доходив до користувачів. Це не посада і не інструмент, а домовленість команди.

Навіщо це менеджеру

Найдорожча помилка: найняти «одного DevOps-інженера» і чекати, що релізи прискоряться самі. Розуміючи практику, ви домовитеся з командою про спільну відповідальність за шлях коду до проду й обґрунтуєте час на автоматизацію.

Де знадобиться

• Продукт із щотижневими релізами кількох команд
• Аутсорс-проєкт, де клієнт вимагає частих демо
• Стартап, що переходить від MVP до стабільної роботи
• Legacy-система з релізами раз на квартал

Як це звучить у команді

• «У нас реліз тільки по п’ятницях, і всі бояться»
• «Це не наша зона, це до адмінів»
• «Хто відповідає за пайплайн?»

Що спитати в команди

Скільки часу минає від злиття змін у Git до проду і хто в команді відповідає за цей шлях, коли щось ламається?

Спершу варто знати: CI/CD

Розібрати на інтенсиві: модуль 4 «DevOps» ↗

Віртуальна машина — це «комп’ютер усередині комп’ютера»: фізичний сервер ділять на кілька ізольованих машин, кожна зі своєю операційною системою. VPS, який орендують у хостинг-провайдера, і є такою машиною, а хмара здає їх тисячами.

Навіщо це менеджеру

Розуміння VM пояснює, за що саме ви платите в хмарі й чому «сервер» можна створити за хвилину або видалити зайвий. Це основа розмов про вартість, резервування ресурсів і прохання команди дати «ще одну машину під stage» (тестове середовище).

Де знадобиться

• Корпоративний портал у приватному дата-центрі
• Хостинг кількох клієнтських сайтів на одному сервері
• Legacy-сервіс, якому потрібна стара версія ОС
• Тестові стенди, що створюються на день і видаляються

Як це звучить у команді

• «Піднімемо ще одну VM під stage»
• «Інстанс замалий, треба збільшити»
• «Це не фізичний сервер, це інстанс у хмарі»

Що спитати в команди

Скільки віртуальних машин у нас працює зараз, які з них простоюють і чи можемо ми вимикати тестові на ніч і на вихідні?

Спершу варто знати: Сервери, VPS і хостинг

Відкриває далі: Масштабування: вертикальне та горизонтальне

Розібрати на інтенсиві: модуль 4 «DevOps» ↗

Моніторинг — це приладова панель системи: збір метрик про те, скільки запитів іде, як швидко вони виконуються, скільки з них падає і чи не закінчується пам’ять на сервері. Без нього про проблеми ви дізнаєтесь від клієнтів.

Навіщо це менеджеру

Метрики перетворюють суперечку «у нас усе працює» на факти: ви бачите, чи витримує прод навантаження й чи не погіршив реліз швидкість. Типова пастка: відкласти моніторинг «на наступний спринт» замість того, щоб мати його з першого релізу.

Де знадобиться

• Сервіс доставки їжі з піковими вечірніми годинами
• SaaS із платними тарифами і гарантіями клієнтам
• Ігровий сервер після виходу оновлення
• Мобільний застосунок після великого запуску

Як це звучить у команді

• «Подивись дашборд, там латентність росте»
• «Помилок 5xx стало більше після релізу»
• «У нас немає метрик для цього сервісу»

Що спитати в команди

Які три метрики показують, що прод здоровий, і де я можу подивитися їх сам, не питаючи розробників?

Спершу варто знати: Середовища: dev, stage, prod

Відкриває далі: Логи та трейсинг, Алерти, інциденти та SLA/SLO, Навантажувальне тестування

Розібрати на інтенсиві: модуль 4 «DevOps» ↗

Логи — це щоденник системи: кожен сервіс записує, що робив і що пішло не так. Трейсинг — окремий сигнал: він показує маршрут одного запиту через усі сервіси з часом на кожному кроці, а спільний trace id дозволяє знайти логи саме цього запиту.

Навіщо це менеджеру

Коли клієнт пише «у мене не пройшла оплата», логи й трейси дають відповідь за хвилини замість днів. Ви зрозумієте, чому команда просить час на «нормальне логування» і чому персональні дані в логах є юридичним ризиком.

Де знадобиться

• Платіжний сервіс, де кожен збій треба пояснити
• Маркетплейс, де замовлення проходить десяток сервісів
• Інтеграція з кількома зовнішніми постачальниками
• Фінтех-продукт, який регулярно проходить аудит

Як це звучить у команді

• «Подивлюся в логи, скажу за десять хвилин»
• «Без trace id ми не зведемо цей запит»
• «Логи за той день уже ротувались»

Що спитати в команди

Якщо клієнт повідомить про збій, що стався вчора, за скільки часу ми знайдемо причину і чи збережені логи за той період?

Спершу варто знати: Моніторинг та метрики

Відкриває далі: Алерти, інциденти та SLA/SLO

Розібрати на інтенсиві: модуль 4 «DevOps» ↗

Вимоги задають, що система має робити (функціональні) і в яких технічних рамках: швидкодія, безпека (нефункціональні). Критерії приймання (acceptance criteria) — умови, за якими задачу вважають виконаною. Як на кухні: не «щось смачне», а «стейк середньої прожарки, без солі».

Навіщо це менеджеру

Розмиті вимоги коштують дорожче за будь-який баг: команда будує не те, оцінки летять, а клієнт чекає іншого. Чіткі критерії приймання дають підставу для оцінки строків і захищають від нескінченного «а ще б додати».

Де знадобиться

• Інтеграція з платіжним провайдером за контрактом
• Держпроєкт із фіксованим ТЗ та тендером
• Мобільний застосунок з офлайн-режимом
• Міграція користувачів зі старої системи

Як це звучить у команді

• «А що має бути, якщо API партнера не відповість?»
• «У тікеті немає критеріїв приймання»
• «Це не баг, так у вимогах не написано»

Що спитати в команди

Чи в кожній задачі спринту є критерії приймання, за якими QA і розробник однаково зрозуміють, що «готово»?

Спершу варто знати: Технічна документація, API

Розібрати на інтенсиві: модуль 5 «Документація» ↗

API-документація описує кожен ендпоінт (адресу для запиту): параметри, формат відповіді, коди помилок; в альтернативах REST, як-от GraphQL чи gRPC, цю роль грає схема. OpenAPI — стандарт такого опису, Swagger UI показує його як сторінку, а Postman дає одразу надсилати запити.

Навіщо це менеджеру

Це те, що ви передаєте партнерам і мобільній команді ще до готового бекенду: можна працювати паралельно. Без актуальної специфікації інтеграції зриваються на «а ми думали, поле обов’язкове», і кожна зміна API стає сюрпризом.

Де знадобиться

• Публічне API для партнерів і сторонніх розробників
• Бекенд, який одночасно споживають iOS, Android і веб
• Маркетплейс, до якого підключаються десятки постачальників
• Платформа з платними API-тарифами для клієнтів

Як це звучить у команді

• «Скинь мені Swagger, я подивлюся контракт»
• «Специфікація не збігається з тим, що повертає бекенд»
• «Є Postman-колекція для тестового стенду»

Що спитати в команди

Чи є в нас актуальна OpenAPI-специфікація, звірена з реальним бекендом, і хто відповідає за її оновлення після кожної зміни API?

Спершу варто знати: REST API, Технічна документація

Розібрати на інтенсиві: модуль 5 «Документація» ↗

Пропускна здатність (bandwidth) — скільки даних проходить за секунду: ширина труби. Затримка (latency) — скільки часу йде один запит туди й назад: довжина труби. Широкий канал не рятує, якщо сервер в іншій півкулі, а сторінка робить сотню запитів.

Навіщо це менеджеру

«Купимо потужніший сервер» часто не допомагає: якщо гальмує мережа, річ у відстані та кількості запитів. Це впливає на вибір регіону хостингу, потребу в CDN (копіях контенту ближче до користувачів) і на розбір скарг «повільно працює».

Де знадобиться

• Сервіс з європейським сервером і клієнтами в Азії
• Мобільний застосунок для регіонів зі слабким зв’язком
• Торгова платформа, де важлива кожна мілісекунда
• Сайт з важкими зображеннями та відео

Як це звучить у команді

• «Пінг до сервера 200 мілісекунд»
• «Тут не ширина каналу, а latency»
• «Сторінка робить 80 запитів, поки завантажиться»

Що спитати в команди

Де фізично стоять наші сервери відносно користувачів, і скільки запитів робить застосунок, щоб показати головний екран?

Спершу варто знати: Мережі: як комп’ютери спілкуються

Розібрати на інтенсиві: модуль 6 «Мережева комунікація» ↗

TCP і UDP — два способи доставки пакетів. TCP гарантує, що все дійде в правильному порядку (рекомендований лист), UDP шле швидко й без підтверджень (листівка). Сайти й API традиційно працюють через TCP, відеодзвінки та ігри — через UDP.

Навіщо це менеджеру

Це визначає, що можна обіцяти клієнту: гарантовану доставку або мінімальну затримку, але не те й інше водночас. Короткі пропуски в дзвінку за поганого зв’язку — компроміс UDP. Якщо ж він затинається на нормальному каналі, перевірте реалізацію, а не протокол.

Де знадобиться

• Онлайн-гра з мультиплеєром у реальному часі
• Платформа для відеоконференцій
• Телеметрія з датчиків на виробництві
• VoIP-телефонія для кол-центру

Як це звучить у команді

• «Голос іде по UDP, тому й обриви»
• «TCP-з’єднання відвалюється через таймаут»
• «Переходимо на HTTP/3, там QUIC поверх UDP»

Що спитати в команди

Що для нашого продукту важливіше: щоб дані дійшли повністю чи щоб дійшли швидко, і чи узгоджений з цим вибір протоколу?

Спершу варто знати: IP-адреси та порти

Відкриває далі: WebSockets та realtime

Розібрати на інтенсиві: модуль 6 «Мережева комунікація» ↗

TLS (стара назва SSL, яку досі вживають) — протокол, який перетворює звичайний HTTP на HTTPS: шифрує трафік між браузером і сервером та підтверджує сертифікатом, що сервер справжній. Як запечатаний конверт із печаткою відправника замість відкритої листівки.

Навіщо це менеджеру

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

Де знадобиться

• Сайт з формою оплати або входу
• Мобільний застосунок, що звертається до власного API
• Публічний лендинг з формою збору лідів
• Внутрішній сервіс, доступний з інтернету

Як це звучить у команді

• «Сертифікат закінчується за три дні, хто продовжує?»
• «У нас на stage самопідписаний сертифікат»
• «Автопродовження сертифіката не спрацювало»

Що спитати в команди

Хто і як продовжує TLS-сертифікати на всіх наших доменах, і чи дізнаємося ми заздалегідь, якщо автопродовження не спрацює?

Спершу варто знати: HTTP та HTTPS, Безпека: що і від кого захищаємо

Відкриває далі: Шифрування та Public Key Encryption

Розібрати на інтенсиві: модуль 7 «Безпека даних та інфраструктури в IT» ↗

Автентифікація відповідає «хто ви?», авторизація — «що вам можна?». Вхід через Google чи Apple працює на OpenID Connect (OIDC) поверх OAuth: OAuth дає доступ до даних, OIDC підтверджує особу, SSO дає один вхід до всіх систем компанії, а JWT — підписаний «пропуск» після входу.

Навіщо це менеджеру

Помилка менеджера: вважати, що «вхід через Google» закриває питання безпеки. Він лише перевіряє особу, а хто до чого має доступ, вирішує ваша логіка ролей, і саме в ній ховаються витоки. Enterprise-клієнти окремо вимагатимуть SSO, щоб керувати доступом самі.

Де знадобиться

• B2B SaaS з корпоративними клієнтами
• Застосунок із входом через соцмережі
• Адмінпанель з різними ролями співробітників
• Партнерське API з різними рівнями доступу

Як це звучить у команді

• «Токен протух, треба refresh»
• «Клієнт вимагає SSO через їхній Microsoft Entra ID»
• «У нас доступи перевіряються тільки на фронті»

Що спитати в команди

Де саме перевіряються права доступу: на бекенді для кожного запиту чи лише в інтерфейсі, і як ми відкликаємо доступ звільненого співробітника?

Спершу варто знати: API, HTTP та HTTPS

Розібрати на інтенсиві: модуль 7 «Безпека даних та інфраструктури в IT» ↗

DDoS — це коли сервер завалюють мільйонами запитів, щоб він перестав відповідати. Фішинг — обман людини задля паролів чи грошей. Ін’єкція — підкидання шкідливих команд у поле введення, які система виконує як свої.

Навіщо це менеджеру

Інциденти зазвичай починаються не з геніального хакера, а з фішингового листа менеджеру чи пароля «123456». Знаючи типи атак, ви правильно розставите пріоритети: навчання команди й 2FA (другий фактор входу) часто дають більше, ніж дорогий WAF (фільтр запитів).

Де знадобиться

• Онлайн-ЗМІ з піковим трафіком під час подій
• Сервіс онлайн-освіти з тисячами студентів
• Бухгалтерія та документообіг компанії
• Крипто- або трейдинг-платформа

Як це звучить у команді

• «Нас DDoS-ять з обіду»
• «Хтось із команди клікнув на фішинг»
• «Там SQL-ін’єкція в полі пошуку»

Що спитати в команди

Що станеться, якщо завтра хтось із команди введе робочий пароль на фішинговому сайті: чи є 2FA і як швидко ми це помітимо?

Спершу варто знати: Безпека: що і від кого захищаємо, Мережі: як комп’ютери спілкуються

Відкриває далі: OWASP Top 10 та захист вебзастосунків, Захист від DDoS: WAF та rate limiting

Розібрати на інтенсиві: модуль 7 «Безпека даних та інфраструктури в IT» ↗

Feature flag — це перемикач у коді, який дозволяє викотити фічу на прод вимкненою, а потім увімкнути її для 1% користувачів, окремої країни чи конкретного клієнта. Так реліз коду й запуск функції стають окремими подіями.

Навіщо це менеджеру

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

Де знадобиться

• A/B-тести нового онбордингу в застосунку
• Поетапний запуск функції по країнах
• Enterprise-продукт з фічами для окремих клієнтів
• Міграція на нового платіжного провайдера без простою

Як це звучить у команді

• «Викотимо під прапорцем»
• «Увімкнемо на 5% і подивимось метрики»
• «Цей прапорець уже пів року нікому не потрібен»

Що спитати в команди

Чи можемо ми вимкнути нову функцію на проді без нового розгортання, хто має доступ до перемикачів, і хто відповідає за прибирання старих прапорців?

Спершу варто знати: CI/CD, Release-стратегії

Розібрати на інтенсиві: модуль 1 «Основи технічної теорії» ↗

Контейнер — застосунок, запакований разом з усіма залежностями так, що він однаково запускається на ноутбуці розробника, на тестовому середовищі і на проді. Docker — стандартний інструмент, щоб збирати і запускати такі «коробки».

Навіщо це менеджеру

Контейнери прибирають класичне «у мене на машині працює» і прискорюють введення нових розробників у проєкт. Але сам Docker не робить систему масштабованою чи стійкою: це лише упаковка, а не керування сотнями таких «коробок» (оркестрація).

Де знадобиться

• Бекенд із десятком сервісів в одній команді
• Команда, де кожен новачок тиждень налаштовує оточення
• Legacy-система зі складним середовищем
• Продукт із частими релізами на кілька середовищ

Як це звучить у команді

• «Загорни це в Docker»
• «Образ важить два гігабайти»
• «У контейнері інша версія бібліотеки»

Що спитати в команди

Чи можна розгорнути наш проєкт на чистій машині однією командою через Docker, і скільки часу це займає в нового розробника?

Спершу варто знати: Середовища: dev, stage, prod, Сервери, VPS і хостинг

Відкриває далі: Моноліт vs мікросервіси, Kubernetes та оркестрація

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

Serverless — модель, де ви не орендуєте і не адмініструєте сервер. Найпоширеніший варіант — функції (AWS Lambda, Cloud Functions, Azure Functions): ви завантажуєте код, хмара запускає його на кожен запит і бере плату за кількість викликів та час їх виконання.

Навіщо це менеджеру

Ідеально для нерегулярних завдань і швидкого старту, але за постійного високого трафіку може вийти дорожче за сервер. Також є «холодний старт» (затримка після паузи) і сильна прив’язка до конкретної хмари: оцініть це до підписання контракту.

Де знадобиться

• Обробка завантажених фото чи документів
• Приймання вебхуків (сповіщень) від платіжних систем
• Бот для Telegram чи Slack
• Нічні звіти й розсилки за розкладом

Як це звучить у команді

• «Винесемо це в Lambda»
• «Холодний старт дає секунду затримки»
• «Функція впирається в ліміт часу виконання»

Що спитати в команди

Що станеться з вартістю і затримкою, якщо трафік на ці функції зросте вдесятеро, і наскільки ми прив’язані до цього провайдера?

Спершу варто знати: Хмара vs on-premise: AWS, GCP, Azure, API

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

Балансувальник — «диспетчер» перед серверами: приймає HTTP-запити користувачів і розподіляє їх між кількома копіями застосунку, оминаючи ті, що не відповідають на перевірку стану.

Навіщо це менеджеру

Для вебзастосунків і API саме балансувальник робить можливими горизонтальне масштабування та оновлення без простою. Це той елемент, який дозволяє пообіцяти клієнту «сайт працюватиме, навіть якщо один сервер впаде».

Де знадобиться

• Продаж квитків із різкими піками попиту
• Публічне API для сотень партнерів
• Новинний портал у день гучної події
• Оновлення застосунку без зупинки сервісу

Як це звучить у команді

• «Поставимо перед ними балансер»
• «Health check не проходить, нода випала»
• «Сесія губиться між серверами»

Що спитати в команди

Скільки копій застосунку працює за балансувальником, і чи виживе сервіс, якщо одна з них раптово вийде з ладу?

Спершу варто знати: Сервери, VPS і хостинг, HTTP та HTTPS

Відкриває далі: Масштабування: вертикальне та горизонтальне, Blue-green, canary та rolling deploy, Захист від DDoS: WAF та rate limiting

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

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

Навіщо це менеджеру

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

Де знадобиться

• Медіасервіс із відео та великими зображеннями
• Продукт з аудиторією на кількох континентах
• Лендинг під масштабну рекламну кампанію
• Мобільна гра із завантаженням ресурсів

Як це звучить у команді

• «Винесемо статику на CDN»
• «Скинь кеш на CDN, картинки старі»
• «Користувачі з Азії бачать стару версію»

Що спитати в команди

Що саме ми роздаємо через CDN, і скільки часу після релізу користувачі можуть бачити стару версію файлів?

Спершу варто знати: HTTP та HTTPS, DNS та домени

Відкриває далі: Захист від DDoS: WAF та rate limiting

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

Кеш — швидка пам’ять, де зберігають готові відповіді, щоб не обчислювати їх щоразу заново і не ходити в базу даних. Redis чи Memcached тримають такі дані в оперативній пам’яті, а HTTP-кеш працює на рівні браузера і проксі.

Навіщо це менеджеру

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

Де знадобиться

• Каталог товарів із мільйонами переглядів
• Стрічка новин або соцмережа
• Сервіс із важкими звітами, які запитують часто
• Сайт із курсами валют чи котируваннями

Як це звучить у команді

• «Закешуємо це в Redis на п’ять хвилин»
• «Кеш протух, треба інвалідувати»
• «Cache hit rate просів після релізу»

Що спитати в команди

Які дані ми кешуємо, як довго вони можуть бути застарілими, і що побачить користувач, якщо Redis раптом впаде?

Спершу варто знати: Реляційні бази даних та SQL, HTTP та HTTPS

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

Черга (RabbitMQ, SQS; Kafka для потоків подій) — «поштова скринька» між сервісами: один кладе завдання, інший забирає, коли готовий. Так відправка листа чи генерація звіту не змушують користувача чекати відповіді.

Навіщо це менеджеру

Черги роблять систему стійкішою до сплесків і збоїв, але додають складність: завдання можуть виконатись двічі, із затримкою або в іншому порядку. Це змінює те, що ви обіцяєте клієнту про «миттєвість».

Де знадобиться

• Масові email- та push-розсилки
• Обробка замовлень у маркетплейсі
• Імпорт великих файлів від клієнтів
• Обмін даними між мікросервісами

Як це звучить у команді

• «Кинемо це в чергу»
• «Черга росте, консюмери не встигають»
• «Повідомлення обробилось двічі»

Що спитати в команди

Що станеться із завданнями в черзі, якщо обробник впаде посеред роботи: вони загубляться, повторяться чи зачекають?

Спершу варто знати: API, Моноліт vs мікросервіси

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

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

Навіщо це менеджеру

Найшкідливіший міф: «мікросервіси — це сучасно, а моноліт застарів». Для невеликої команди мікросервіси множать вартість інфраструктури, тестування й пошуку помилок. Рішення має йти від розміру команди та навантаження, а не від моди.

Де знадобиться

• MVP із командою до п’яти розробників
• Платформа, яку розробляють кілька незалежних команд
• Поділ старого моноліту на частини
• Система з різним навантаженням на модулі

Як це звучить у команді

• «Винесемо це в окремий сервіс»
• «Деплой моноліту блокує всі команди»
• «Між сервісами гуляє мережева затримка»

Що спитати в команди

Скільки в нас сервісів, скільки людей їх підтримує, і чи не витрачаємо ми більше часу на інфраструктуру, ніж на функції для клієнта?

Спершу варто знати: API, Docker і контейнери

Відкриває далі: Черги повідомлень та асинхронність, Типові архітектури проєктів

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

Більшість продуктів збудовано за кількома впізнаваними схемами: тришарова (клієнт, бекенд, база), моноліт із чергами, мікросервіси за API-шлюзом, serverless-ланцюжки. Знаючи їх, ви впізнаєте свій проєкт на схемі за хвилину.

Навіщо це менеджеру

Типова архітектура — це готові відповіді на питання про строки, команду і вартість: скільки компонентів розгортати, де вузькі місця і що ламається першим. Так пропозицію підрядника можна обговорювати предметно, а не на віру.

Де знадобиться

• Оцінка архітектури від нового підрядника
• B2B SaaS для багатьох клієнтів на одній базі
• Мобільний застосунок із бекендом і адмінпанеллю
• Перехід від MVP до масштабованої платформи

Як це звучить у команді

• «У нас класична тришарова схема»
• «Ставимо API gateway перед сервісами»
• «Намалюй, як це все з’єднано»

Що спитати в команди

Чи можете за десять хвилин намалювати нашу архітектуру на дошці і показати, який компонент відмовить першим, коли навантаження зросте?

Спершу варто знати: Моноліт vs мікросервіси, Реляційні бази даних та SQL, Хмара vs on-premise: AWS, GCP, Azure

Відкриває далі: Архітектурні діаграми: C4, Lucidchart, draw.io

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

Індекс — це «зміст» таблиці, за яким база знаходить потрібні рядки без перегляду всіх. Без індексів запити повільнішають зі зростанням даних; зайві індекси сповільнюють запис.

Навіщо це менеджеру

Коли продукт «гальмує» після зростання, причина часто в одному запиті без індексу, а не в потребі купувати потужніший сервер. Це рятує бюджет і дає підставу виділити час на оптимізацію.

Де знадобиться

• Пошук і фільтри в каталозі на мільйони позицій
• Звіти в адмінці, що будуються хвилинами
• Стрічка подій з фільтрами за датою
• Логістика з пошуком за трек-номерами

Як це звучить у команді

• «Запит робить full scan по таблиці»
• «Треба подивитися EXPLAIN»
• «Повісимо індекс на цю колонку»

Що спитати в команди

Які запити за даними моніторингу зараз найповільніші: це проблема індексів чи нам справді потрібне потужніше залізо?

Спершу варто знати: Реляційні бази даних та SQL

Відкриває далі: Шардинг бази даних

Розібрати на інтенсиві: модуль 3 «Бази даних та їх особливості» ↗

Транзакція — група операцій, що виконується або повністю, або ніяк, як переказ грошей з одного рахунку на інший. ACID — чотири гарантії бази: атомарність, узгодженість, ізоляція (паралельні операції не заважають одна одній) і довговічність (підтверджені дані переживуть збій).

Навіщо це менеджеру

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

Де знадобиться

• Мобільний банкінг з переказами між рахунками
• Резервування місць з оплатою
• Складський облік із залишками
• Маркетплейс з розподілом виплат продавцям

Як це звучить у команді

• «Тут потрібна транзакція, інакше дані розійдуться»
• «Ловимо deadlock під навантаженням»
• «Тут можна пожертвувати консистентністю»

Що спитати в команди

Що станеться із замовленням і грошима, якщо сервер впаде посередині оплати, і як ми це перевіряли?

Спершу варто знати: Реляційні бази даних та SQL

Розібрати на інтенсиві: модуль 3 «Бази даних та їх особливості» ↗

Реплікація — автоматичне копіювання даних з головної бази (primary) на її копії (репліки). Репліки для читання приймають частину запитів і розвантажують головну базу; у разі збою одна з реплік може стати головною.

Навіщо це менеджеру

Реплікація дає стійкість і швидкість, але за асинхронної схеми репліка відстає від головної: зазвичай на мілісекунди, а під навантаженням і на секунди. Це пояснює баги «зберіг, а не бачу» і допомагає планувати, що обіцяти клієнту про доступність.

Де знадобиться

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

Як це звучить у команді

• «Читання йде з репліки, звідси затримка»
• «Replication lag виріс до хвилини»
• «Робимо failover на репліку»

Що спитати в команди

Чи є в нас репліка бази, яке в неї типове відставання і чи перемикання на неї в разі збою відбувається автоматично?

Спершу варто знати: Реляційні бази даних та SQL

Відкриває далі: Відмовостійкість та disaster recovery, Шардинг бази даних

Розібрати на інтенсиві: модуль 3 «Бази даних та їх особливості» ↗

ETL (Extract, Transform, Load) — процес, що регулярно забирає дані з різних джерел, очищує й переносить їх у сховище для аналітики; у варіанті ELT дані трансформують уже всередині сховища. Data pipeline — конвеєр таких кроків за розкладом або безперервно.

Навіщо це менеджеру

Звіти і дашборди хороші рівно настільки, наскільки надійний конвеєр даних. Розуміння ETL дає змогу оцінити строки впровадження нової метрики і зрозуміти, чому «цифри не сходяться» після зміни продукту.

Де знадобиться

• Об’єднання даних з CRM, реклами та платежів
• Щоденне вивантаження для фінансової звітності
• Синхронізація каталогу між сайтом і ERP
• Підготовка даних для моделі рекомендацій

Як це звучить у команді

• «Пайплайн впав уночі, дані за вчора не долилися»
• «Треба додати ще одне джерело в ETL»
• «Це буде батч раз на годину»

Що спитати в команди

Що станеться зі звітами, якщо конвеєр даних зламається вночі, хто це побачить і як швидко ми довантажимо втрачені дані?

Спершу варто знати: Реляційні бази даних та SQL, NoSQL: документні та key-value бази

Відкриває далі: BI та аналітика даних, Data Warehouse та Data Lake

Розібрати на інтенсиві: модуль 3 «Бази даних та їх особливості» ↗

BI (Business Intelligence) — інструменти на кшталт Power BI, Metabase чи Looker, що перетворюють дані з бази на дашборди й звіти без участі розробників. Аналітик збирає графік сам, а не чекає, поки бекенд зробить для нього окреме вивантаження.

Навіщо це менеджеру

BI знімає з команди розробки чергу «зроби мені звіт» і показує, чи є в продукті дані для рішень. Але BI не виправляє поганих даних: сміття на вході дає гарний, але брехливий графік.

Де знадобиться

• Дашборд продажів для керівництва мережі магазинів
• Воронка конверсії в SaaS-продукті
• Звітність для інвесторів у стартапі
• Контроль KPI кол-центру

Як це звучить у команді

• «Підключимо Metabase прямо до репліки»
• «Цей звіт кладе базу, треба окреме сховище»
• «У дашборді цифри не збігаються з бухгалтерією»

Що спитати в команди

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

Спершу варто знати: ETL та Data Pipeline

Відкриває далі: Data Warehouse та Data Lake

Розібрати на інтенсиві: модуль 3 «Бази даних та їх особливості» ↗

Алерт — сигнал, що метрика перетнула поріг і хтось має реагувати. Інцидент — збій, що зачепив користувачів; управління інцидентами описує процес: хто чергує, як ескалюють, як пишуть постмортем. SLO — внутрішня ціль надійності, зазвичай суворіша за SLA, обіцянку в договорі.

Навіщо це менеджеру

Ви не пообіцяєте клієнту в SLA «чотири дев’ятки» (99,99%), якщо метрики показують три (99,9%): це десятикратна різниця в дозволеному простої. А бюджет помилок (error budget) дає аргумент, коли час зупинити фічі заради надійності.

Де знадобиться

• B2B-платформа з договірними гарантіями доступності
• Платіжний шлюз, де хвилина простою коштує грошей
• Сервіс 24/7 із черговими інженерами (on-call)
• Медичний або страховий сервіс із регуляторними вимогами

Як це звучить у команді

• «Хто сьогодні on-call?»
• «Ми спалили error budget за тиждень»
• «Треба написати постмортем до п’ятниці»

Що спитати в команди

Який у нас SLO на доступність і час відповіді, скільки бюджету помилок витрачено цього місяця і хто отримує алерт о третій ночі?

Спершу варто знати: Моніторинг та метрики, Логи та трейсинг

Розібрати на інтенсиві: модуль 4 «DevOps» ↗

Infrastructure as Code — це підхід, за якого сервери, мережі й бази в хмарі описують у файлах (Terraform, Pulumi, CloudFormation), а не налаштовують кліками у вебконсолі хмари. Інфраструктуру рев’юють, версіюють у Git і розгортають через CI/CD, як звичайний код.

Навіщо це менеджеру

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

Де знадобиться

• Продукт з окремим середовищем для кожного клієнта
• Міграція між хмарними провайдерами або регіонами
• Аварійне відновлення (disaster recovery) з нуля
• Компанія з десятками сервісів і кількома командами

Як це звучить у команді

• «Це зроблено руками в консолі, у Terraform цього нема»
• «Plan показує, що воно хоче видалити базу»
• «Дрифт: реальна інфра відрізняється від коду»

Що спитати в команди

Якщо завтра доведеться підняти всю інфраструктуру з нуля в новому акаунті, скільки часу це забере і чи все описано в коді, а не налаштовано вручну?

Спершу варто знати: Хмара vs on-premise: AWS, GCP, Azure, CI/CD

Розібрати на інтенсиві: модуль 4 «DevOps» ↗

Стратегії розгортання — це способи викотити нову версію без зупинки сервісу. Blue-green тримає дві копії середовища й перемикає трафік між ними; canary пускає нову версію на невелику частку користувачів; rolling оновлює сервери по черзі, поки решта обслуговують трафік.

Навіщо це менеджеру

Стратегія визначає ціну помилки в релізі: із blue-green відкат триває секунди, поки стара копія жива і схема бази сумісна з обома версіями; з canary проблему побачить лише частка користувачів. Це дозволяє обіцяти клієнту релізи в робочий час без вікна простою.

Де знадобиться

• Інтернет-банкінг, де неприпустиме вікно простою
• Стрімінговий сервіс із безперервними сесіями глядачів
• Реліз нового алгоритму рекомендацій у маркетплейсі
• Глобальний SaaS без «нічного вікна» для всіх часових зон

Як це звучить у команді

• «Викотили на canary, дивимось метрики годину»
• «Перемикаємо трафік на green»
• «Міграція бази несумісна з двома версіями одночасно»

Що спитати в команди

Як ми викочуємо нову версію на прод, за скільки хвилин відкотимося, якщо метрики погіршаться, і чи сумісна схема бази з обома версіями?

Спершу варто знати: Release-стратегії, CI/CD, Балансування навантаження

Розібрати на інтенсиві: модуль 4 «DevOps» ↗

Архітектурна діаграма показує, з яких частин складається система і як вони спілкуються. Модель C4 має чотири рівні: контекст із зовнішніми системами, контейнери (застосунки, бази даних), компоненти і код; зазвичай вистачає перших двох-трьох. Малюють у Lucidchart чи draw.io.

Навіщо це менеджеру

Одна діаграма замінює годину пояснень: видно, де живуть дані клієнта, що впаде, якщо система партнера недоступна, і що міняти під час переходу на мікросервіси. Помилка: вважати схему на wiki актуальною, не питаючи, коли її малювали.

Де знадобиться

• Аудит архітектури перед due diligence інвестора
• Розділення моноліту на сервіси
• Пресейл для корпоративного клієнта з вимогами до безпеки
• Система з кількома зовнішніми інтеграціями та чергами

Як це звучить у команді

• «Намалюй C4 рівня контейнерів для нового сервісу»
• «На схемі цього сервісу ще немає»
• «Ця схема ще з попередньої архітектури»

Що спитати в команди

Чи є актуальна діаграма системи, на якій видно всі зовнішні інтеграції та місця зберігання персональних даних?

Спершу варто знати: Технічна документація, Типові архітектури проєктів

Розібрати на інтенсиві: модуль 5 «Документація» ↗

ADR (Architecture Decision Record) — короткий запис одного технічного рішення: контекст, альтернативи, вибір і наслідки. RFC (Request for Comments) — документ-пропозиція, яку команда обговорює, перш ніж почати робити. Разом вони зберігають не лише «що вирішили», а й «чому».

Навіщо це менеджеру

Через пів року ніхто не пам’ятає, чому обрали цю базу даних чи відмовилися від мікросервісів, і команда повторює старі суперечки. ADR дає вам аргументи для клієнта та захищає від переписування «бо новому тімліду не подобається».

Де знадобиться

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

Як це звучить у команді

• «Напиши RFC, обговоримо на архітектурному рев’ю»
• «Є ADR, чому ми не взяли Kafka»
• «Це рішення ніде не зафіксоване»

Що спитати в команди

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

Спершу варто знати: Технічна документація, Code review та якість коду

Розібрати на інтенсиві: модуль 5 «Документація» ↗

Звичайний HTTP працює як запит-відповідь: клієнт спитав, сервер відповів, розмова закінчилась. WebSocket тримає постійне з’єднання, і сервер сам надсилає дані, щойно вони з’явилися: нове повідомлення, курс, статус замовлення.

Навіщо це менеджеру

Оновлення в реальному часі здається простою фічею, але змінює архітектуру: тисячі відкритих з’єднань навантажують сервер інакше, ніж окремі запити, і ускладнюють масштабування та балансування. Оцінка «чат за тиждень» без цього буде хибною.

Де знадобиться

• Чат або служба підтримки всередині застосунку
• Трекінг кур’єра на мапі в реальному часі
• Спільне редагування документів
• Біржовий термінал з живими котируваннями

Як це звучить у команді

• «Тут polling не підійде, потрібен WebSocket»
• «Балансер рве довгі з’єднання»
• «Скільки одночасних з’єднань витримаємо?»

Що спитати в команди

Скільки одночасних відкритих з’єднань витримає наш бекенд, і що побачить користувач, якщо з’єднання обірветься на хвилину?

Спершу варто знати: TCP та UDP, HTTP та HTTPS

Розібрати на інтенсиві: модуль 6 «Мережева комунікація» ↗

Проксі — посередник, через який клієнт ходить назовні. Reverse proxy — посередник перед вашими серверами: приймає всі запити, знімає шифрування HTTPS і розподіляє їх між бекендами (Nginx, Traefik). VPN — зашифрований тунель у приватну мережу.

Навіщо це менеджеру

Без reverse proxy складно робити релізи з нульовим простоєм, обмежувати кількість запитів і ховати внутрішні сервери. VPN визначає, як підрядники й віддалені колеги дістаються до бази та тестового середовища (stage), і це питання безпеки, а не зручності.

Де знадобиться

• Доступ віддаленої команди до внутрішніх систем
• Кілька бекендів за одним публічним доменом
• Робота підрядника зі stage-середовищем
• Корпоративний застосунок, доступний лише з VPN

Як це звучить у команді

• «Nginx стоїть перед усіма сервісами»
• «Без VPN до stage не достукаєшся»
• «Проксі повертає 502 Bad Gateway»

Що спитати в команди

Що стоїть перед нашими серверами, хто має VPN-доступ до внутрішньої мережі і як ми його відкликаємо, коли людина йде з проєкту?

Спершу варто знати: IP-адреси та порти, DNS та домени

Розібрати на інтенсиві: модуль 6 «Мережева комунікація» ↗

OWASP Top 10 — це відкритий перелік найпоширеніших вразливостей вебзастосунків: зламаний контроль доступу, ін’єкції, помилки автентифікації, небезпечні налаштування, вразливі сторонні бібліотеки. Галузевий чекліст, за яким аудитори перевіряють ваш продукт.

Навіщо це менеджеру

Клієнти й пентестери (фахівці, що імітують атаку на продукт) посилаються на OWASP як на стандарт, тож «ми його враховуємо» має бути правдою. Автоматичні сканери в CI ловлять частину проблем, але зламану логіку доступів знайде тільки людина під час code review.

Де знадобиться

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

Як це звучить у команді

• «Пентест знайшов IDOR в ендпоінті замовлень»
• «Dependabot підсвітив критичну вразливість»
• «Треба закрити SAST-репорт до релізу»

Що спитати в команди

Коли ми востаннє проходили пентест або сканування за OWASP, і які зі знайдених вразливостей досі не закриті?

Спершу варто знати: Типи кібератак: DDoS, фішинг, ін’єкції, Code review та якість коду

Розібрати на інтенсиві: модуль 7 «Безпека даних та інфраструктури в IT» ↗

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

Навіщо це менеджеру

Розрізняйте «шифрування під час передачі» (TLS) і «шифрування у спокої» (бази, бекапи, диски): клієнти й аудитори питають про обидва. Приватний ключ, що витік, обнуляє все шифрування, тож зберігання ключів важливіше за алгоритм.

Де знадобиться

• Месенджер з наскрізним шифруванням
• Зберігання сканів документів та паспортів
• Сервіс з бекапами клієнтських даних у хмарі
• Обмін даними з банком через підписані файли

Як це звучить у команді

• «Дані в базі шифруються at rest»
• «Ключі ротуємо раз на квартал»
• «Паролі треба хешувати, а не шифрувати»

Що спитати в команди

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

Спершу варто знати: SSL/TLS: як працює HTTPS

Відкриває далі: SSH та доступ до серверів, Комплаєнс та аудит: GDPR, PCI DSS, SOC 2

Розібрати на інтенсиві: модуль 7 «Безпека даних та інфраструктури в IT» ↗

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

Навіщо це менеджеру

Доступ через SSH — це фактично ключ від серверної. Якщо він є в усіх «про всяк випадок», то коли співробітник звільняється, ніхто не згадає його забрати. Менеджеру важливо знати, хто має доступ до prod і чи ведеться журнал входів.

Де знадобиться

• Продукт на власних VPS без хмарної консолі
• Зміна підрядника з передачею доступів до серверів
• Legacy-система на фізичному сервері в офісі
• Аутстаф-команда з доступом до серверів клієнта

Як це звучить у команді

• «Скинь свій публічний ключ, додам на сервер»
• «На prod заходимо тільки через bastion»
• «Хто ще досі має ключ від старого сервера?»

Що спитати в команди

Скільки людей мають SSH-доступ до prod, чи вимкнений вхід за паролем, і як швидко ми відкликаємо ключ, коли людина йде з проєкту?

Спершу варто знати: Сервери, VPS і хостинг, Шифрування та Public Key Encryption

Відкриває далі: Секрети, ключі та керування доступами

Розібрати на інтенсиві: модуль 7 «Безпека даних та інфраструктури в IT» ↗

Секрети — це паролі до баз, API-ключі, токени й сертифікати, якими сервіси доводять, що їм можна. Їх зберігають не в коді, а у спеціальних сховищах (vault, secret manager), і видають кожному середовищу свої.

Навіщо це менеджеру

Класична катастрофа: ключ від хмари випадково потрапив у Git, і за ніч чужі боти запустили на ньому сервери за ваш рахунок. Правило «секрети окремо від коду, prod окремо від dev» дешевше за будь-який інцидент, і його варто перевірити особисто.

Де знадобиться

• Проєкт з десятками сторонніх інтеграцій
• Мікросервіси, що розгортаються через CI/CD
• Продукт з ізольованими середовищами для клієнтів
• Публічний репозиторій комерційної компанії

Як це звучить у команді

• «Ключ засвітився в репозиторії, треба ротувати»
• «Секрети тягнемо з Vault на старті»
• «У .env на проді лежить ключ від dev»

Що спитати в команди

Де зберігаються prod-секрети, хто їх бачить, і коли ми востаннє змінювали (ротували) ключі після того, як хтось пішов із проєкту?

Спершу варто знати: Середовища: dev, stage, prod, CI/CD, SSH та доступ до серверів

Розібрати на інтенсиві: модуль 7 «Безпека даних та інфраструктури в IT» ↗

Kubernetes — система, яка керує сотнями контейнерів: запускає їх на потрібних серверах, перезапускає впалі, додає копії під навантаження і проводить оновлення без простою. Оркестрація — це саме таке «диригування».

Навіщо це менеджеру

Kubernetes потужний, але дорогий у фахівцях: потрібен окремий DevOps-досвід і час на налаштування. Для невеликого продукту він часто зайвий, і рішення про нього має враховувати бюджет на команду, а не лише на сервери.

Де знадобиться

• Платформа з десятками мікросервісів
• Продукт із автоматичним масштабуванням під трафік
• SaaS у кількох регіонах для корпоративних клієнтів
• Продукт, що розгортається в кількох хмарах або on-premise

Як це звучить у команді

• «Под перезапускається в циклі»
• «Треба додати ноди в кластер»
• «Helm-чарт зламався після оновлення»

Що спитати в команди

Хто в команді реально вміє полагодити кластер о третій ночі, і чи не вирішив би наші завдання простіший сервіс запуску контейнерів без власного кластера?

Спершу варто знати: Docker і контейнери, Масштабування: вертикальне та горизонтальне

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

Вертикальне масштабування — купити потужніший сервер. Горизонтальне — додати ще кілька однакових серверів і розподілити навантаження між ними через балансувальник.

Навіщо це менеджеру

Вертикальне просте, але має стелю і єдину точку відмови. Горизонтальне вимагає застосунку, готового до нього (дані користувача не прив’язані до одного сервера). З’ясувати це варто до підписання SLA, а не після падіння в «чорну п’ятницю».

Де знадобиться

• Розпродаж із десятикратним стрибком трафіку
• Стрімінг спортивних трансляцій
• Освітня платформа перед сесією
• Державний сервіс із мільйонами користувачів

Як це звучить у команді

• «Додамо CPU і пам’яті, поки що вистачить»
• «Застосунок не stateless, не розмножиться»
• «Автоскейлінг спрацював запізно»

Що спитати в команди

Якщо завтра трафік зросте вдесятеро, ми додамо сервери чи переписуватимемо код, і скільки часу займе кожен варіант?

Спершу варто знати: Балансування навантаження, Віртуальні машини

Відкриває далі: Kubernetes та оркестрація, Відмовостійкість та disaster recovery, Вартість інфраструктури (FinOps), Шардинг бази даних, Навантажувальне тестування

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

Висока доступність (high availability) — здатність сервісу працювати далі або швидко відновлюватись, коли ламається сервер, база чи дата-центр, завдяки дублюванню й автоматичному перемиканню. Disaster recovery — план відновлення з бекапів і резервних регіонів після катастрофи.

Навіщо це менеджеру

Кожна додаткова «дев’ятка» доступності (99,9% проти 99,99%) коштує кратно дорожче, тож обіцяти клієнту «чотири дев’ятки» без бюджету на резервування небезпечно. Ваші робочі метрики: RTO (скільки простоїмо) і RPO (скільки даних втратимо).

Де знадобиться

• Еквайринг, який не має права зупинятися ні на хвилину
• Медична система з даними пацієнтів
• Логістична платформа для мережі складів
• Продукт з інфраструктурою в зоні бойових дій

Як це звучить у команді

• «Failover спрацював сам, ніхто не прокинувся»
• «Наш RPO — година, більше не втратимо»
• «Треба другий регіон для DR»

Що спитати в команди

Якщо основний регіон або дата-центр зникне на годину, що перемкнеться автоматично, що доведеться робити руками, і скільки хвилин простою ми пообіцяли клієнту?

Спершу варто знати: Масштабування: вертикальне та горизонтальне, Реплікація та read-репліки, Бекапи та відновлення даних

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

FinOps — практика керування витратами на хмару: хто, за що і скільки платить, які ресурси простоюють і як пов’язати рахунок із бізнес-показниками. Рахунок за хмару стає таким самим об’єктом менеджменту, як зарплатний фонд.

Навіщо це менеджеру

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

Де знадобиться

• Продукт, де рахунок за хмару росте швидше за виручку
• Аутсорс-проєкт, де клієнт платить за інфраструктуру
• Стартап, який ріже витрати перед раундом
• Компанія з кількома хмарними акаунтами й командами

Як це звучить у команді

• «Хто залишив увімкненим stage на вихідних?»
• «Візьмемо reserved instances на рік»
• «Тегуємо ресурси за проєктами»

Що спитати в команди

Скільки коштує інфраструктура на одного активного користувача, і які три найбільші статті в рахунку за минулий місяць?

Спершу варто знати: Хмара vs on-premise: AWS, GCP, Azure, Масштабування: вертикальне та горизонтальне

Розібрати на інтенсиві: модуль 2 «Інфраструктура» ↗

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

Навіщо це менеджеру

Шардинг радикально ускладнює код, звіти й транзакції між шардами, а повернути все назад майже неможливо. Не дайте команді шардувати «на виріст», але й не пропустіть момент, коли це вже справді потрібно.

Де знадобиться

• Месенджер з мільярдами повідомлень
• Глобальна ігрова платформа з регіонами
• Рекламна мережа з потоком подій
• Фінтех-платформа, що обслуговує десятки банків

Як це звучить у команді

• «Обираємо shard key, від нього все залежить»
• «Цей запит треба зібрати з усіх шардів»
• «Перебалансування шардів займе тиждень»

Що спитати в команди

У що саме ми впираємося зараз (диск, запис чи читання) і які варіанти ми вичерпали до шардингу?

Спершу варто знати: Реплікація та read-репліки, Індекси та продуктивність запитів, Масштабування: вертикальне та горизонтальне

Розібрати на інтенсиві: модуль 3 «Бази даних та їх особливості» ↗

Data Warehouse (DWH) — централізоване сховище очищених, структурованих даних для звітності (BigQuery, Snowflake, ClickHouse). Data Lake — сховище «сирих» даних будь-якого формату, які складають про запас і розбирають пізніше.

Навіщо це менеджеру

Окреме сховище не дає важким аналітичним запитам перевантажувати робочу базу і збирає всі дані компанії в одному місці. Пастка: Data Lake без власника й каталогу стає «болотом» даних, за які платять, але ними не користуються.

Де знадобиться

• Аналітика поведінки користувачів у великому маркетплейсі
• Об’єднана звітність холдингу з десятка систем
• Навчання ML-моделей на історичних даних
• Зберігання телеметрії авто чи обладнання

Як це звучить у команді

• «Заллємо сирі події в lake, розберемося пізніше»
• «Вітрина даних оновлюється раз на добу»
• «Запит у DWH коштує грошей за кожен терабайт»

Що спитати в команди

Хто відповідає за якість і каталог даних у сховищі і скільки ми платимо за зберігання й запити щомісяця?

Спершу варто знати: ETL та Data Pipeline, BI та аналітика даних

Розібрати на інтенсиві: модуль 3 «Бази даних та їх особливості» ↗

Навантажувальне тестування — це репетиція піку: систему навмисно засипають запитами за допомогою інструментів на кшталт k6, Gatling чи Locust, щоб знайти, де вона ламається, ще до «чорної п’ятниці» чи запуску реклами. Результат читають через метрики, а не «начебто витримало».

Навіщо це менеджеру

Це єдиний спосіб відповісти клієнту на «а витримаємо ми в десять разів більше?» цифрами, а не сподіваннями. Ви побачите, чи справді рятує додавання серверів (горизонтальне масштабування), чи все впирається в базу, і скільки коштуватиме резерв.

Де знадобиться

• Продаж квитків на концерт із стартом о фіксованій годині
• Інтернет-магазин перед сезонним розпродажем
• Держсервіс, який запускають для всієї країни одразу
• Освітня платформа перед стартом вступної кампанії

Як це звучить у команді

• «Під навантаженням першою лягає база»
• «Треба прогнати load test на stage перед релізом»
• «Знайшли вузьке місце: пул з’єднань до бази»

Що спитати в команди

На якому навантаженні ми тестували систему востаннє, який компонент відмовив першим і наскільки це вище за очікуваний пік запуску?

Спершу варто знати: Тестування: unit, integration, e2e, Моніторинг та метрики, Масштабування: вертикальне та горизонтальне

Розібрати на інтенсиві: модуль 4 «DevOps» ↗

Захист від DDoS будують шарами: CDN і anti-DDoS-провайдер приймають на себе основний потік, WAF відсіює шкідливі запити за правилами, а rate limiting обмежує кількість звернень з однієї адреси чи акаунта. Балансувальник лише розподіляє те, що пройшло крізь ці шари, а не захищає.

Навіщо це менеджеру

Помилка: «нас прикриє хостинг». Базовий захист хмари відбиває лише грубі атаки на мережу, а атаку на важкі для сервера операції (пошук, вхід) зупинять тільки WAF і ліміти запитів. Захист — це також стаття витрат, яку варто закласти до запуску.

Де знадобиться

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

Як це звучить у команді

• «Увімкнули under attack mode на CDN»
• «WAF ріже легітимних користувачів»
• «Треба поставити rate limit на логін»

Що спитати в команди

Що станеться з продуктом, якщо завтра на нас підуть з десятикратним трафіком: хто вмикає захист, за скільки хвилин, і скільки це коштуватиме?

Спершу варто знати: Типи кібератак: DDoS, фішинг, ін’єкції, CDN, Балансування навантаження

Розібрати на інтенсиві: модуль 7 «Безпека даних та інфраструктури в IT» ↗

Комплаєнс — це відповідність зовнішнім правилам. GDPR регулює персональні дані всіх людей у ЄС незалежно від громадянства, PCI DSS стосується карткових даних, а SOC 2 підтверджує незалежним аудитом, що процеси безпеки справді працюють. Це не разова галочка, а режим життя команди.

Навіщо це менеджеру

Комплаєнс впливає на архітектуру і строки: де зберігати дані, як довго тримати бекапи, чи можна записувати email у логи. Enterprise-клієнти часто не підпишуть контракт без SOC 2, тому питання «чи нам це треба» ставте на етапі планування, а не продажів.

Де знадобиться

• SaaS для клієнтів з ЄС або США
• Платіжний сервіс або власна обробка карток
• HR-tech з даними кандидатів та зарплатами
• Телемедицина або застосунок для здоров’я

Як це звучить у команді

• «Клієнт прислав security-опитувальник перед контрактом»
• «Треба DPA і право на видалення даних»
• «Аудитор просить логи доступу за рік»

Що спитати в команди

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

Спершу варто знати: Безпека: що і від кого захищаємо, Шифрування та Public Key Encryption, Бекапи та відновлення даних

Розібрати на інтенсиві: модуль 7 «Безпека даних та інфраструктури в IT» ↗