У межах ініціативи Security Hardening ми впровадили підхід Access as Code для керування доступами в AWS. Для кожного репозиторію створюється окрема IAM-роль з permissions відповідно до принципу Least Privilege. Управління ролями винесене в централізований репозиторій, де кожен сервіс описується одним YAML-файлом. Усі зміни проходять через Pull Requests та approvals, а за допомогою Terraform і Atlantis ролі автоматично створюються або оновлюються. У результаті ми отримали масштабоване, аудитоване та безпечне керування доступами без прямого доступу команд до AWS.

Ця доповідь - про реальний DevOps-проєкт, досвід якого виявився дуже схожим на сюжет книги «Проєкт Фенікс». Я розповім про повний шлях: побудову платформи, міграцію, роботу з командами розробки, комунікацію з бізнесом, життя системи під навантаженням і ті помилки, які стають видимими лише з часом. Це не переказ книги і не success story. Це розмова про системні рішення, відповідальність, навчання, підготовку до інцидентів і про те, як складні технічні системи формують поведінку людей усередині них. Доповідь сфокусована не на інструментах, а на висновках, які з’являються лише тоді, коли проєкт проживається цілком - від задуму до реальності продакшну.

У кожного інженера — своя дорога в IT. Моя почалася не з красивих презентацій і чітких планів, а з того, що мене на крані піднімали ремонтувати екран на стадіоні «Металіст». Потім були телеком-проєкти, автотести, Red Hat, OpenStack, OpenShift — і постійний пошук, куди рухатися далі. З часом прості кострубаті скрипти, які я писав лише щоб зекономити собі кілька годин, почали тримати прод. «Пожежі» стали приводами для нових рішень, а експерименти — досвідом, який справді працює. І десь у цьому всьому були моменти, коли я хотів піти з IT. Але натомість з’явилися DevOps01, ком’юніті, а згодом — AWS та HashiCorp-амбасадорство. У цьому виступі я розповім, як постійний пошук себе у професії та професії в собі став тим самим двигуном, що змінив не лише кар’єру, а й життя. Як маленькі ініціативи виростають у великі системи, а спільнота відкриває нові двері.

Ця доповідь присвячена практичному досвіду переходу з класичної Istio-архітектури з sidecar-контейнерами на нову модель — Istio Ambient Mesh. Ми розповімо, як масштабування мікросервісної інфраструктури на Kubernetes призвело до зростання витрат на ресурси, ускладнення CI/CD та затримок у запуску сервісів. Пошук рішень привів нас до впровадження Ambient Mesh — архітектури без sidecar-контейнерів, яка значно спрощує mesh-інтеграцію і знижує інфраструктурні витрати. У доповіді буде детально розглянуто технічні аспекти міграції: як ми готувалися до переходу, які виклики виникали у процесі впровадження та як вдалося їх подолати у співпраці зі спільнотою Istio. Поділимось результатами, аналітикою, реальними метриками до/після та дамо практичні поради командам, які планують впровадження Ambient Mesh у production.

Готові зруйнувати стіни між девелоперами та DevOps і прибрати із себе частину роботи? В своєму quick talk хочу поділитись своїм досвідом про те, як ми покращили співпрацю між командами та яку частину роботи можна і навіть корисно передавати девелоперам.

Останні три роки я процюю в LetsEnhance/Claid, стартапі який покращує картинки та генерує новий фон для продуктів. І хоча інфра, вона і в африці інфра, але є нюанс: великі моделі, затримки, автоскейлінг. В цій доповіді я хочу поспілкуватись на тему наших поглядів на AI інфраструктуру і що і як можна виправити (теоретично %%божевільний сміх%%) Тема орієнтована на мід\сініорів які чи вже трішечки крутять АІ, чи просто цікавляться як там обслуговують те що нас замінить.

In this presentation I will try to analyze the experience of using pgbouncer and other database proxies at prom.ua. What profit does it bring in organizational sense, what new flexibility it gives to the infrastructure and everyday maintenance and scaling, which additional enchancements we managed to implement and test, what worked and what did not.

В цій доповіді я спробую проаналізувати досвід використання pgbouncer і побічно інших проксі до бази даних в проекті prom.ua. Яку вигоду несе використання проксі в організаційному плані, яку гнучкість додає інфраструктурі в процесі підтримки та масштабування, які додаткові покращення ми змогли розробити та протестувати, що запрацювало і що ні.

Під час виступу Микита поділиться досвідом Solidgate у побудові високопродуктивної фінтех-платформи з таргетом на високий аптайм, використовуючи SaaS рішення від AWS. Він розкриє еволюційний шлях масштабування від однієї RDS Postgres до 100+ RDS/Aurora з безшовними оновленнями для кінцевих користувачів, поділиться нюансами взаємодії з “managed” рішенням та потенційними прихованими витратами на обслуговування, щоб відповідати вимогам продукту і надавати краще технічне рішення.