У нас есть служба поддержки платформы которая занимается разбором проблем и инцидентов на конвейере.
Не атакуют разработчиков платформы?)
Не атакуют или очень редко доходят прям проблемные факторы. Тогда разработка подключается к исправлению, но обычно все остается на 1/2 линии.
И заметил, что разраб-ки сервисов имеют возможность контролировать ресурсы в кубере, они прям реально что-то там замеряют и тюнят под МР-, препрод-, прод-стенды?
Да обычно это делают совместно с тестировщиками. Так как есть требование по предоставлению каждого сервиса его метрик то разработчик и тестировщик всегда могут найти нужную информацию в Графане для тюнинга приложения.
Или всем проставляется дефолт при создании сервиса и, максимум на проде как начинает торомозить, что-то себе увеличивают?
У нас в РСХБ есть процесс по получению ресурсов, он конечно несколько сложен, но если верхнеуровнево написать, то обычно проходит несколько этапов от Архитектурного виденья и заканчивая получением запрошенных ресурсов. Если начинает тормозить, обычно есть оперативный резерв для подкидывания дровишек.
Но служба поддержки платформы всегда следит за показателями потребления и обычно приходит в центр разработки задолго как это станет проблемой.
Поэтому таких случаев, что прям в тротлинг уходило, что-то на платформе у нас 1-2 случая было. И обычно это связано, с какой-либо акцией, о которой не предупредил бизнес техническое сопровождение системы и народ на сервис навалился и приложил его, кончено в этих случаях иногда спасает HPA.
Мы начали разрабатывать платформу ещё в 2020 году. Вдохновлялись подходами GitOps, тогда был тренд на "давайте опишем все как код". Старались создать интересный инструмент для разработчиков Банка, который бы покрыл потребности разработчиков и предоставил бы единообразный инструмент для них.
Хороший вопрос. Но думаю, что в ближайшие 10-12 лет на рынке софта РФ, все будет сводиться к регуляторике и контролю за производством софта. Поэтому вопрос поддержки, в плане ОС, не будет стоять на повестке, все будет обновляться лататься и зашиваться, на это будут выделяться средства.
Если говорить про комьюнити софт и Opensource, то решения широко используемые сообществом в случае закрытия core-девелопера продолжат поддерживаться силами сообщества или перейдут в фонд открытого ПО.
Если вы говорите про стандартный инфраструктурный стек, то да в целом это так и есть стандартный надежный стек.
Было бы интересно прочитать о том, что вы пробовали, почему не понравилось и в итоге выбрали то, что выбрали
В будущем, мы расскажем подробнее про компоненты платформы - платформенных операторов(их у нас несколько), портал управления платформой, а также про интеграционную подсистему. Данная статья является обзорной про платформу в целом, и рассказывает о ее возможностях не погружаясь в подробности.
Спасибо за вопросы.
У нас есть служба поддержки платформы которая занимается разбором проблем и инцидентов на конвейере.
Не атакуют или очень редко доходят прям проблемные факторы. Тогда разработка подключается к исправлению, но обычно все остается на 1/2 линии.
Да обычно это делают совместно с тестировщиками. Так как есть требование по предоставлению каждого сервиса его метрик то разработчик и тестировщик всегда могут найти нужную информацию в Графане для тюнинга приложения.
У нас в РСХБ есть процесс по получению ресурсов, он конечно несколько сложен, но если верхнеуровнево написать, то обычно проходит несколько этапов от Архитектурного виденья и заканчивая получением запрошенных ресурсов.
Если начинает тормозить, обычно есть оперативный резерв для подкидывания дровишек.
Но служба поддержки платформы всегда следит за показателями потребления и обычно приходит в центр разработки задолго как это станет проблемой.
Поэтому таких случаев, что прям в тротлинг уходило, что-то на платформе у нас 1-2 случая было. И обычно это связано, с какой-либо акцией, о которой не предупредил бизнес техническое сопровождение системы и народ на сервис навалился и приложил его, кончено в этих случаях иногда спасает HPA.
Мы начали разрабатывать платформу ещё в 2020 году. Вдохновлялись подходами GitOps, тогда был тренд на "давайте опишем все как код". Старались создать интересный инструмент для разработчиков Банка, который бы покрыл потребности разработчиков и предоставил бы единообразный инструмент для них.
Хороший вопрос. Но думаю, что в ближайшие 10-12 лет на рынке софта РФ, все будет сводиться к регуляторике и контролю за производством софта. Поэтому вопрос поддержки, в плане ОС, не будет стоять на повестке, все будет обновляться лататься и зашиваться, на это будут выделяться средства.
Если говорить про комьюнити софт и Opensource, то решения широко используемые сообществом в случае закрытия core-девелопера продолжат поддерживаться силами сообщества или перейдут в фонд открытого ПО.
Если прочитать поверхностно статью, то будет:
Если вы говорите про стандартный инфраструктурный стек, то да в целом это так и есть стандартный надежный стек.
В будущем, мы расскажем подробнее про компоненты платформы - платформенных операторов(их у нас несколько), портал управления платформой, а также про интеграционную подсистему. Данная статья является обзорной про платформу в целом, и рассказывает о ее возможностях не погружаясь в подробности.
del