какое ценообразование, sla, заключаете ли всякие baa/nda
Здесь все индивидуально, от пожеланий клиента. Если совсем кратко, то ценообразование зависит от 4 основных пунктов:
Количество приложений и задействованных инфраструктурных решений
Нагрузка на приложения
Где хостится инфраструктура (облако или железки)
Требований/пожеланий клиента: реагирование 24/7, SLA, динамические окружения в CI/CD и т. д.
Интересует с чем работаете (кубы, базы, kv, ёлка),
Кубы везде, за место елик EFK используем, намного удобнее (если речь в основном про логирование). Базы в основном Managed, в основном PostgreSql, иногда операторы в кубере когда на это есть показания + у нас есть свой клауд (https://kvindo.ru), там был интересный опыт разработки Managed HA PostgreSql c PITR на PgBackRest, Patroni, Etcd и HaProxy
ПС: По клауду если зайдете, не судите строго, сыроват пока, на своих клиентах пока в основном доводим до кондиций)
есть ли опыт сопровождения инфраструктуры под Iso27001
Именно такого нет, но ранее когда еще в штате работал, проходил аудит по PCIDSS v3 на инфраструктуре в AWS (в то время 3 версия была самой сложной).
И главный вопрос - работаете ли с Европой (включая геморрой с платежами, английский и прочее).
Опыта не много, хотя попробовать интересно и мы готовы открыть юр лицо вне РФ. По английскому: я хорошо знаю, займусь сам, если требуется много не текстовых коммуникаций
ПС: Мой никнейм в Telegram QTU100, можем там списаться или организовать звонок
Мне кажется вы используете слишком много инструментов для достижения одной цели, и каждый из них добавляет свой собственный maintenance overhead. В плане что вы говорите взять эластик для логов, егерь для apm, пром для метрик и графану для визуализации. Хотя по факту можно взять эластик для логов, его же для apm, в него же лить метрики и им же делать визуализацию. Да, придётся брать облако и подписку (либо opensearch), и часть вещей заменить не выйдет (sentry работает с ошибками куда лучше), но в итоге у вас будет единая система мониторинга с меньшим количеством точек отказа и гораздо более простой поддержкой
Да, в целом согласен. Для небольшой собственной команды из 1-3х инженеров использовать 1 инструмент, пусть и с некоторыми ограничениями - то что надо, но мы DevOps аутсорс, мы можем выделить достаточно много времени на готовку и отладку + ожидания от нас повыше
Ну и вы упомянули бизнес метрики рядом с техническими. По личному опыту это прямой путь в ад. Продукту проше дать ro на базу (и возможно отдельные вьюхи) и настругать event'ы на каждый чих, а дальше пусть сами берут себе airflow, metabase, tableau, хоть черта лысого - это не ваша зона ответственности, и вы не бизнес-аналитик, вы девопс. Вы просто следите чтоб эвенты капали и база жила, а продукт может крутить чего хочет
Тут я больше имел в виду те бизнес метрики, которые потенциально сильно коррелируют с состоянием инфраструктуры (кол-во платежей, кол-во регистраций, кол-во входов). Метрики вроде среднего чека уже явно не наша зона, не могу не согласиться
Плюс базу можно иметь ресурсом куба, наверняка есть операторы которые и создадут и удалят.
Это верно подмечено, разве что стоит также подметить что база частенько деплоится не на кубере, а отдельно на виртуалки или используется менеджед сервис и в этом случае это решение не подойдет
И сидинг лучше не через бэкап делать а через нормальный сидинг данных из кода. Он же пригодится и разработчикам при локальной разработке.
Безусловно. Но часто разработчики "очень заняты" и вариант с копированием их устраивает больше поскольку не требует их вовлечения
В целом задача хорошо решается через argocd, там есть генераторы которые следят за репо и видят новые каталоги. Просто скопировали каталог с манифестами или чартами - и у вас новое приложение в другом неймспейсе.
А можно тут поподробнее если не сложно? Как через него организовать создание окружения из ветки (даже если опустить момент с копированием базы)?
Но в целом, мы не используем арго для приложений, только для инфраструктурных сервисов. Потому что:
Не видно процесса и статуса деплоя в Gitlab, это не удобно
Нет возможности делать --atomic релизы
Иногда требуется добавить доп логику завязанную на процесс деплоя (например, сброс кеша на Cloudflare, отправка оповещалок в Telegram). Если деплой организован через арго, то это становится проблематичной задачей (все решаемо конечно, но уже сложнее)
Сайт: https://avant-it.ru/
Презентация: https://avant-it.ru/wp-content/uploads/2024/08/avantit-1.pdf
Здесь все индивидуально, от пожеланий клиента. Если совсем кратко, то ценообразование зависит от 4 основных пунктов:
Количество приложений и задействованных инфраструктурных решений
Нагрузка на приложения
Где хостится инфраструктура (облако или железки)
Требований/пожеланий клиента: реагирование 24/7, SLA, динамические окружения в CI/CD и т. д.
Кубы везде, за место елик EFK используем, намного удобнее (если речь в основном про логирование). Базы в основном Managed, в основном PostgreSql, иногда операторы в кубере когда на это есть показания + у нас есть свой клауд (https://kvindo.ru), там был интересный опыт разработки Managed HA PostgreSql c PITR на PgBackRest, Patroni, Etcd и HaProxy
ПС: По клауду если зайдете, не судите строго, сыроват пока, на своих клиентах пока в основном доводим до кондиций)
Именно такого нет, но ранее когда еще в штате работал, проходил аудит по PCIDSS v3 на инфраструктуре в AWS (в то время 3 версия была самой сложной).
Опыта не много, хотя попробовать интересно и мы готовы открыть юр лицо вне РФ.
По английскому: я хорошо знаю, займусь сам, если требуется много не текстовых коммуникаций
ПС: Мой никнейм в Telegram QTU100, можем там списаться или организовать звонок
Да, так действительно лучше, спасибо =)
Да, в целом согласен. Для небольшой собственной команды из 1-3х инженеров использовать 1 инструмент, пусть и с некоторыми ограничениями - то что надо, но мы DevOps аутсорс, мы можем выделить достаточно много времени на готовку и отладку + ожидания от нас повыше
Тут я больше имел в виду те бизнес метрики, которые потенциально сильно коррелируют с состоянием инфраструктуры (кол-во платежей, кол-во регистраций, кол-во входов). Метрики вроде среднего чека уже явно не наша зона, не могу не согласиться
Это верно подмечено, разве что стоит также подметить что база частенько деплоится не на кубере, а отдельно на виртуалки или используется менеджед сервис и в этом случае это решение не подойдет
Безусловно. Но часто разработчики "очень заняты" и вариант с копированием их устраивает больше поскольку не требует их вовлечения
А можно тут поподробнее если не сложно? Как через него организовать создание окружения из ветки (даже если опустить момент с копированием базы)?
Но в целом, мы не используем арго для приложений, только для инфраструктурных сервисов. Потому что:
Не видно процесса и статуса деплоя в Gitlab, это не удобно
Нет возможности делать --atomic релизы
Иногда требуется добавить доп логику завязанную на процесс деплоя (например, сброс кеша на Cloudflare, отправка оповещалок в Telegram). Если деплой организован через арго, то это становится проблематичной задачей (все решаемо конечно, но уже сложнее)
Поправил, теперь ссылка доступна без входа👍