GraphQL — это круто, но как его документировать, чтобы разработчики не задавали лишних вопросов?

В статье:
• сравниваем GraphQL и REST, чтобы было понятно даже новичкам;
• показываем, как «оживить» схему с помощью комментариев и примеров кода;
• объясняем, как собрать статический справочник, если GraphiQL недоступен.

«Как оценить возврат инвестиций» — вебинар уже через час!

Многие внедряют DevOps-практики, но не могут доказать их ценность цифрами.

На вебинаре покажем подход, который связывает скорость доставки и качество релизов с экономическим эффектом.

Разберём:
• Подходы к оценке ROI, такие как обзор трансформации (сверху вниз) и детальная оценка отдельных изменений (снизу вверх).
• Пример анализа ROI на компании среднего размера.
• Как DevOps-практики сокращают трудозатраты и оптимизируют процессы.

Сегодня, 5 декабря, 12:00 (мск)

Не забудьте зарегистрироваться →

Андрей Радыгин видел много инфраструктур и миграций, поэтому неплохо представляет, что обычно идёт не так.

В статье по мотивам доклада с DevOpsConf он разбирает, что важно учесть при переезде в облака или на on-prem: от расчёта полной стоимости миграции и нематериальных рисков до особенностей managed-сервисов и архитектуры отказоустойчивых систем.

Заглядывайте на Хабр за формулами подробным разбором того, о чём стоит подумать заранее.

В высоконагруженных финтех-сервисах шардирование — это путь к масштабированию без потери SLA.

ЕДИНЫЙ ЦУПИС — это высоконагруженный финтех-проект. За год совместной работы система получила геораспределённую отказоустойчивую архитектуру: шардировали платёжную логику, инфраструктуру и мониторинг, четыре кластера объединили в единый service mesh, два из них — на площадке с PCI DSS. Было непросто, зато теперь там живёт масштабируемая система без просадки по надёжности. Сейчас платформа справляется с 30 релизами в сутки, суммарное SLA мультиЦОД-инсталляции превышает 99,99%.

Сегодня на митапе у коллег разберём, как в таких высоконагруженных проектах устроена наблюдаемость.

Владимир Гурьянов, технический директор продукта Deckhouse Observability Platform, покажет, как устроен мониторинг, который переваривает свыше 100 млн метрик, почему классические подходы не подходят под такую нагрузку и как решаются вопросы с хранением и шардированием метрик в мультитенантной архитектуре.

Многие знают, как репликация и шардирование реализованы в классических, реляционных базах данных. Доклад позволит иначе взглянуть на привычные задачи, и вы сможете использовать эти подходы в своих проектах, даже если они не связаны с метриками.

9 декабря, 18:30, Санкт-Петербург. Подробности →

Когда GitLab CI начинает запускать задачи с задержкой по 10 минут и сжигать деньги на «вечно живущие» EC2‑инстансы, приходится что‑то менять. 

Мы настроили масштабируемые GitLab Runner’ы через Fleeting и Autoscaler и в итоге заметно сократили затраты на CI‑инфраструктуру в AWS. В этой статье делимся конфигурациями, схемой и пошаговым гайдом, чтобы вы могли повторить этот подход у себя.

В новой статье — лучшие практики по конфигурациям в Kubernetes, которые спасут вас от нерабочих подов после обновления API, багов в CI и хаоса в проде. Лайфхаки от тех, кто каждый день работает с кластерами.

Команда Deckhouse Storage рассказала о поддерживаемых в наших платформах CSI — как о вариантах с использованием реализаций от вендора, так и о разработанном нами универсальном модуле, который поддерживает интеграцию с практически любым СХД.

Вышла новая версия Kubernetes — 1.35. Собрали подробный обзор всех нововведений на русском языке.

Из важного: отслеживание здоровья устройств при DRA, асинхронная обработка API-вызовов и новая разновидность YAML для описания конфигураций — эти и другие фичи и изменения появились в Kubernetes 1.34.

Приятного изучения →

Асинхронная репликация + failover = риск потери данных. Но вот не все знают, что даже если все транзакции уже ушли на реплику, можно потерять данные при переключении. Особенно если есть логическая репликация и настроен nofailover: true.

При ручном failover Patroni не синхронизирует логические слоты заранее. И если логическая реплика отстаёт — часть данных может исчезнуть навсегда.

Рассказали, почему так происходит и как это исправить.

Флант большую часть своей истории занимается DevOps-сопровождением проектов. Со временем мы стали продуктовой компанией, появилась экосистема Deckhouse, случилось слияние с Экспресс 42.

Это расширило возможности направления DevOps as a Service— собственные инструменты и продукты обеспечивают круглосуточное сопровождение с реакцией на инциденты с SLA в пять минут.

DevOps as a Service — это когда команда экспертов берёт на себя задачи SRE, построение и сопровождение DevOps-цикла, помогает с архитектурой приложений. Работаем 24/7 с гарантией реакции 5 минут по SLA.

Помогает, когда продукту не хватает ресурсов на DevOps-задачи, когда команда вместо создания продукта тушит пожары на инфраструктуре, когда CTO устал просыпаться по ночам из-за упавшего прода.

Для тех, кто сталкивался с подобными задачами и хочет попробовать, как это работает, мы подготовили специальное предложение. Подробности →