Към основното съдържание
FromNine
Меню

Разработка

Облачна основа, с която новите версии стават рутина.

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

За организации, които поддържат една облачна основа за дружества в няколко държави членки, всяко със свой надзорен орган.

Обсъдете проекта сиПримерна архитектура
Облак и платформен инженеринг: слоеве на услугатаЧетири слоя, наредени един зад друг. Отгоре надолу: системите на продуктовите екипи, вътрешната платформа за разработчици, подписаните конвейери за доставка и в основата landing zone с идентичност, мрежа и правила.01Системи на продуктовите екипи02Вътрешна платформа за разработчици03Подписани конвейери за доставка04Landing zone и правила
  1. 01Landing zone с правила като код и местоположение на данните, определено за всяка система
  2. 02Стандартни пътища, които водят нова услуга до експлоатация по повторим начин
  3. 03Цели за нивото на услугата, проверено възстановяване и разход по продукти, видими за хората, които решават

01 Проблеми

Признаци, че основата Ви пречи

  1. 01

    Всяка среда е уникална

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

  2. 02

    Новата версия изисква среща

    Внедряванията са редки, ръчни и насрочени за вечерта. Екипите събират промените накуп, което прави всяка нова версия по-рискова.

  3. 03

    Сметката за облака изненадва всички

    Разходите се виждат по абонаменти, а не по продукти. Капацитетът от графични процесори за AI задачи е запазен от този, който е поискал пръв.

  4. 04

    Никой не знае дали възстано­вяването работи

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

02 Какво доставяме

Какво доставяме

  1. 01 Landing zone и варианти за суверенитет

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

    Какво правим

    • Проектиране на организацията, групите за управление и акаунтите
    • Централна мрежа, контрол на изходящия трафик и частна свързаност
    • Правила като код за местоположение, криптиране и етикетиране
    • Съпоставяне с удостоверенията, които изискват клиентите Ви, например BSI C5 в Германия или SecNumCloud във Франция

    Какво получавате

    • Landing zone, описана изцяло като код
    • Библиотека с правила и процес за изключения
    • Документ с вариантите за суверенитет за всеки клас системи

  2. 02 Инфра­структура като код и вътрешни платформи за разработчици

    Terraform или OpenTofu и Bicep за инфраструктурата, GitOps за внедряванията, Kubernetes или управлявани среди за изпълнение, където са подходящи, и стандартни пътища, така че екипът да стартира услуга, отговаряща на изискванията, без да подава заявки.

    Какво правим

    • Библиотека от модули за инфраструктура като код
    • GitOps с последователно преминаване през средите
    • Платформа с Kubernetes или управлявани алтернативи
    • Шаблони за услуги и портал за разработчици

    Какво получавате

    • Вътрешна платформа за разработчици със стандартни пътища
    • Среди на самообслужване
    • Пътна карта на платформата, за която отговаря платформен екип

  3. 03 Конвейери за доставка и сигурност на веригата за доставки на софтуер

    Конвейери, които изграждат веднъж, подписват артефактите, записват произхода им в съответствие със SLSA, управляват правилно тайните и пренасят един и същ артефакт от тестовата до продуктивната среда.

    Какво правим

    • Шаблони за конвейери с проверки за качество и сигурност
    • Подписване на артефактите и удостоверяване на произхода
    • Управление на тайните и ротация на ключовете
    • Правила за пренасяне и записи за промените

    Какво получавате

    • Шаблони за конвейери за многократна употреба
    • Подписани артефакти с проверим произход
    • Доказателства за всяка версия за управлението на промените

  4. 04 Наблюдаемост и SRE

    Цели за нивото на услугата, уговорени с бизнеса, бюджети за грешки, които определят темпото на новите версии, OpenTelemetry в целия стек и процес за инциденти, който обслужва и задълженията за докладване по Закона за киберсигурност и по DORA, когато се отнасят до Вас.

    Какво правим

    • Определяне на целите за нивото на услугата с отговорниците
    • Инструментиране с OpenTelemetry и табла
    • Известия по симптоми, а не по причини
    • Управление на инциденти и прегледи след инцидент

    Какво получавате

    • Каталог на целите за нивото на услугата
    • Стек за наблюдение и табла
    • Ръководства за инциденти и докладване

  5. 05 FinOps и капацитет за AI

    Разпределение на разходите по продукти и екипи, единични разходи като цена на транзакция и планиране на капацитета от графични процесори и контрол на разходите за AI системи.

    Какво правим

    • Правила за етикетиране и модел за разпределение
    • Показатели за единичния разход по продукти
    • Планиране на ангажименти и резервации
    • Разпределение на графичните процесори, квоти и оразмеряване

    Какво получавате

    • Табла с разходите за всеки продуктов отговорник
    • Списък с възможни спестявания и отговорници
    • План за капацитета за AI

  6. 06 Възстано­вяване и изход

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

    Какво правим

    • RTO и RPO, уговорени за всяка услуга
    • Тестове за възстановяване и превключване
    • Карта на зависимостите на критичните услуги
    • План за изход и проверки за преносимост на данните

    Какво получавате

    • Тествани процедури за възстановяване
    • Доклади от тестовете за възстановяване
    • Документирана стратегия за изход

03 Архитектура

Примерна референтна архитектура

Кодът влиза отляво, а работещите системи излизат отдясно. Между тях конвейерът подписва изгражданото, регистърът съхранява само подписани артефакти, а GitOps контролер ги пренася през средите според правилата.

Отдолу е landing zone: структура на организацията, идентичност, мрежа, ключове, възстановяване и контрол на разходите, описани веднъж като код и общи за всички продуктови екипи.

Слоеве в диаграмата

Доставка
Хранилища, конвейери, подписани артефакти и пренасяне чрез GitOps.
Платформа
Платформата за разработчици, правилата като код и средата за изпълнение, в която продуктовите екипи внедряват.
Базова среда (landing zone)
Организация, идентичност, мрежа, ключове, възстановяване и контрол на разходите.
Експлоатация
Телеметрия, цели за нивото на услугата, бюджети за грешки и реакция при инциденти навсякъде.
Илюстративен пример

  1. Доставка

    • Хранилища за код и IaC
    • Изграждане, подпис, удостове­ряване
    • Регистър с подписани артефакти
    • Пренасяне чрез GitOps

  2. Платформа

    • Платформа и стандартни пътища
    • Правила като код
    • Kubernetes и управлявани услуги
    • Системи на продуктовите екипи

  3. Базова среда (landing zone)

    • Структура за управление
    • Идентичност и достъп
    • Централна мрежа и изходящ трафик
    • Ключове и тайни
    • Резервни копия и възстано­вяване
    • Разпределение на разходите

  4. Експлоатация

    • OpenTelemetry, цели и бюджети за грешки, реакция при инциденти
Подписана доставка върху landing zone с правила

Примерна архитектура, а не система на клиент.

Прочетете диаграмата като текст

Основният маршрут води от хранилищата за код и инфраструктура през конвейери, които изграждат, подписват и удостоверяват, към регистър на артефактите, след това към GitOps контролер и накрая към средите на продуктовите екипи.

Вътрешната платформа за разработчици дава стандартни пътища към конвейерите. Правилата като код ограничават GitOps контролера. Платформа за изпълнение с Kubernetes и управлявани услуги хоства системите. Ключовете, управлявани от клиента, захранват слоя с правила.

Landing zone отдолу съдържа структурата за управление, идентичността и достъпа, централната мрежа, ключовете, резервните копия и възстановяването и контрола на разходите. Наблюдението с цели за нивото на услугата и реакцията при инциденти обхващат цялата платформа.

04 Съображения и ограничения

Инженерни съображения и ограничения

  • Суверенитетът има степени

    Как го решаваме

    Класифицираме системите по чувствителност и съпоставяме всеки клас с вариант: региони в ЕС на голям облачен доставчик, суверенна облачна услуга или собствена инфраструктура. Компромисите по функции, разходи и експлоатация се записват.

    Ограничения и зависимости

    Суверенните услуги често изостават при управляваните услуги, включително при AI услугите. Някои системи там ще струват повече или ще могат по-малко, и това е бизнес избор.

  • Платформата има нужда от продуктов отговорник

    Как го решаваме

    Разглеждаме вътрешната платформа като продукт с потребители, пътна карта и обратна връзка и Ви помагаме да създадете екипа, който я поддържа.

    Ограничения и зависимости

    Платформа без екип се превръща в тясно място. Ако не можете да осигурите хора за нея, ще препоръчаме управлявани услуги и по-малко абстракции.

  • Регулациите оформят експлоа­тацията

    Как го решаваме

    Класифицирането на инциденти, сроковете за докладване и събирането на доказателства се вграждат в процеса за инциденти, когато Законът за киберсигурност или DORA се прилагат за Вас.

    Ограничения и зависимости

    Дали попадате в обхвата и как се прилага за Вас националният закон, остава задача на Вашите екипи по съответствие и на юристите Ви.

  • Контролът на разходите е обща задача

    Как го решаваме

    Правим разходите видими по продукти и добавяме предпазни мерки като бюджети, квоти и планирано спиране на неизползвани среди.

    Ограничения и зависимости

    Най-големите спестявания обикновено идват от решения за архитектурата и използването, които вземат продуктовите отговорници, а не само от платформата.

05 Как работим

Как работим

Първо основата, после един екип по стандартния път, после всички останали.

  1. 01

    Оценяваме и класифицираме

    Системите, чувствителността на данните, сегашните разходи и контролите, които одиторите Ви очакват.

    РезултатКласификация на системите и целеви варианти

  2. 02

    Изграждаме landing zone

    Всичко като код, прегледано с отдела по сигурност, с процес за изключения.

    РезултатLanding zone в експлоатация

  3. 03

    Включваме първия екип

    Един продуктов екип преминава към стандартния път; трудностите, които среща, оформят платформата.

    РезултатПърва услуга на платформата

  4. 04

    Разширяваме и предаваме

    Включват се още екипи, платформеният екип поема отговорността, а възстановяването се тества по график.

    РезултатПътна карта на платформата и доклади от тестовете за възстано­вяване

06 Човешки контрол

Къде контролът остава у хората

Автоматизацията управлява платформата. Хората отговарят за решенията, които носят риск или разход.

  • Промените в продуктивната среда са проследими

    Всяка промяна в продуктивната среда идва от прегледан commit, така че кой какво е променил и кой го е одобрил винаги е записано.

  • Аварийният достъп е рядък и се записва

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

  • Изключенията от правилата имат отговорник

    Когато дадена система има нужда от изключение от предпазно правило, определен отговорник за риска го одобрява, с краен срок.

  • Отговорниците за услугите определят целите

    Целите за възстановяване и нивата на услугата се уговарят с бизнес отговорника за всяка услуга, а не се определят само от платформения екип.

07 Технологии

Технологии, с които работим

Облак
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Европейски суверенни облачни услуги
Инфра­структура и доставка
  • Terraform и OpenTofu
  • Bicep
  • Argo CD и Flux
  • GitHub Actions, GitLab CI и Azure DevOps
Среда за изпълнение
  • Kubernetes и управлявани варианти
  • Платформи за безсървърни приложения и контейнери
  • Service mesh, където се отплаща
  • Възли с графични процесори за AI системи
Експлоатация
  • OpenTelemetry
  • Prometheus и Grafana
  • Вградено наблюдение на облачните платформи
  • Механизми за правила като OPA

Посочването на технология описва инженерния ни опит. То не означава партньорство с нейния производител или одобрение от него.

08 Пример

Илюстративен пример

Илюстративен пример

Обща landing zone за група с дружества в България и още две държави

01Ситуация
Три дъщерни дружества, едно от които в България, използват отделни облачни среди с различни контроли. Всяко попада под националния закон, който въвежда NIS2 в своята държава, със свои срокове за докладване, и никой не може да покаже състоянието на сигурността в групата на едно място.
02Какво бихме изградили
Една landing zone, описана като код, с отделни набори от правила за всяко дружество, общи журнали и процес за инциденти, който класифицира и насочва докладите според държавата.
03Къде решават хората
Отговорникът по сигурността на всяко дружество одобрява изключенията от правилата за своите системи; ръководителят по информационна сигурност на групата отговаря за общата базова линия.
04Какво бихме измервали
Време от откриването на инцидент до класифицирането му, дял на системите под правила и успешни тестове за възстановяване на тримесечие.

09 По сектори

Във Вашия сектор

  • Публичен сектор

    Варианти за суверенитет за всеки клас данни, мерки по Закона за киберсигурност за административните органи и планове за изход, които издържат и при следващата обществена поръчка.

  • Финансови услуги

    Оперативна устойчивост по DORA: тествано възстановяване, надзор върху доставчиците на ИКТ услуги и докладване на инциденти, вградени в експлоатацията.

България

Доказателства веднъж, за всеки надзорен орган

NIS2 е една директива, но националните закони, които я въвеждат, се различават по обхват, регистрация и подробности при докладването. За финансовите субекти се добавя DORA със собствени правила за докладване на инциденти и надзор върху трети страни. Група, която работи в няколко държави, има нужда от една платформа, която дава доказателствата, изисквани от всеки орган.

В България измененият Закон за киберсигурност е в сила от 17 февруари 2026 г. Компетентните органи за секторите се определят с решение на Министерския съвет, Министерството на иновациите и дигиталната трансформация е компетентен орган за административните органи, а уведомленията за инциденти минават през екипите за реагиране при инциденти с компютърната сигурност. По DORA надзорът е при Българската народна банка (БНБ) за банките и платежните институции и при Комисията за финансов надзор (КФН) за застрахователите, инвестиционните и пенсионните дружества.

Проектираме landing zone, в която местоположението на данните, журналите и класификацията на инцидентите са правила, а не отделни проекти, така че ново дружество или нова държава се добавя чрез конфигурация. Плановете за изход стъпват на правото на смяна на доставчика по Акта за данните на ЕС и се тестват, а не само се описват.

Въпроси за облака и платформения инженеринг

Кой облачен доставчик препоръчвате?

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

Нужен ли ни е Kubernetes?

Не винаги. Kubernetes се отплаща, когато имате много услуги и екип, който да поддържа платформата. За няколко услуги управляваните платформи за контейнери или безсървърни приложения често са по-прости и по-евтини за поддръжка.

Как подхождате към сигурността?

Сигурността е вградена в landing zone и в конвейерите: идентичности с минимални права, правила като код, подписани артефакти и тайни, които никога не стоят в кода. Самата FromNine е сертифицирана по ISO/IEC 27001 за управление на информационната сигурност.

Можете ли да намалите разходите ни за облак?

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

Как да избегнем обвързване с един доставчик?

Като съзнателно избирате къде да зависите от специфични услуги на доставчика, поддържате инфраструктурата като код и имате документиран и тестван план за изход. Актът за данните на ЕС засилва правото Ви да смените доставчика; планът за изход го прави приложимо на практика.

Покажете ни следващите си три версии

Ще Ви кажем какво би ги превърнало в рутина и колко би струвало изграждането и поддръжката на тази основа.

Обсъдете проекта сиВижте консултациите