Pull to refresh

Comments 5

Напоминает платформы для микросервисов в Авито и Сбере: вдохновлялись или до всего сами дошли?

Мы начали разрабатывать платформу ещё в 2020 году. Вдохновлялись подходами GitOps, тогда был тренд на "давайте опишем все как код". Старались создать интересный инструмент для разработчиков Банка, который бы покрыл потребности разработчиков и предоставил бы единообразный инструмент для них.

А в итоге, кто разбирается с падениями джоб? У вас же тоже рядовые разраб-ки не умеют в gitlab-ci, докер, кубер и что-то там argo-like? Не атакуют разработчиков платформы?) И заметил, что разраб-ки сервисов имеют возможность контролировать ресурсы в кубере, они прям реально что-то там замеряют и тюнят под МР-, препрод-, прод-стенды? Или всем проставляется дефолт при создании сервиса и, максимум на проде как начинает торомозить, что-то себе увеличивают?

Спасибо за вопросы.

А в итоге, кто разбирается с падениями джоб?

У нас есть служба поддержки платформы которая занимается разбором проблем и инцидентов на конвейере.

Не атакуют разработчиков платформы?)

Не атакуют или очень редко доходят прям проблемные факторы. Тогда разработка подключается к исправлению, но обычно все остается на 1/2 линии.

И заметил, что разраб-ки сервисов имеют возможность контролировать ресурсы в кубере, они прям реально что-то там замеряют и тюнят под МР-, препрод-, прод-стенды?

Да обычно это делают совместно с тестировщиками. Так как есть требование по предоставлению каждого сервиса его метрик то разработчик и тестировщик всегда могут найти нужную информацию в Графане для тюнинга приложения.

Или всем проставляется дефолт при создании сервиса и, максимум на проде как начинает торомозить, что-то себе увеличивают?

У нас в РСХБ есть процесс по получению ресурсов, он конечно несколько сложен, но если верхнеуровнево написать, то обычно проходит несколько этапов от Архитектурного виденья и заканчивая получением запрошенных ресурсов.
Если начинает тормозить, обычно есть оперативный резерв для подкидывания дровишек.

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

Поэтому таких случаев, что прям в тротлинг уходило, что-то на платформе у нас 1-2 случая было. И обычно это связано, с какой-либо акцией, о которой не предупредил бизнес техническое сопровождение системы и народ на сервис навалился и приложил его, кончено в этих случаях иногда спасает HPA.

А вам спасибо за ответы) Видимо, поддержка платформы мастхэв, а то нам приходится дежурить по очереди. Только судя по специфическим кейсам обращений такую поддержку вряд ли получится покрыть инструкциями, и ее сотрудник будет мало отличаться от разработчика) Но, честно говоря, мы и не пробовали, может постепенно и можно подготовить людей.

Sign up to leave a comment.