Comments 8
Сейчас в планах — минимизировать time-to-market нашей единой системы
Добрый день, какие шаги для этого будут сделаны? Давно слышу о минимизации, есть ли результаты?
0
Добрый день!
Минимизация time-to-market означает, что мы должны иметь релизный цикл с короткими итерациями и возможность выпускать отдельные фичи независимо друг от друга. Т.е.:
— Быстро тестировать.
— Быстро выкатывать новые версии.
— Быстро обнаруживать и исправлять проблемы после выкатки.
— Разделить систему на много независимо поставляемых приложений.
Мы движемся в направлении микросервисной архитектуры, которая и позволяет реализовать все эти задачи.
Она хорошо подходит при масштабах Сбербанка. Только над фронт-офисными приложениями у нас работают сотни команд.
По микросервисам рекомендую изучить статью Фаулера: martinfowler.com/articles/microservices.html или ее перевод: habr.com/post/249183
Микросервисный подход отлично ложится и на новую организационную структуру, построенную на принципах agile.
В частности, этим летом централизованную эксплуатацию разнесли по agile-командам.
Тем самым, созданы предпосылки для построения devops-культуры, которая необходима для успешной эксплуатации микросервисов.
Важными моментами для независимого выпуска фич являются:
— Обратная совместимость на уровне API. Обеспечить ее помогают такие шаблоны проектирования, как Consumer Driven Contracts martinfowler.com/articles/consumerDrivenContracts.html
и Tolerant Reader martinfowler.com/bliki/TolerantReader.html
— Возможность включения/выключения отдельных фич (или старой и новой версий фичи) в рамках одного приложения. Тут помогает шаблон Feature Toggle (https://martinfowler.com/bliki/FeatureToggle.html).
Разумеется, помимо этого, есть огромный пласт работ, которые сделаны или делаются для обеспечения эксплуатации микросервисов:
— Внедрение контейнеризации. Сейчас пилотируется OpenShift.
— Devops pipelines.
— Автотесты, в том числе тесты API на совместимость.
— Разрабатывается собственный API gateway на основе nginx.
— Централизованное логирование с возможность находить логи в рамках одного запроса по correlation token.
— Различные механизмы защиты от отказов, например, квотирование в разрезе потребителей сервиса. Другой пример — аналог hystrix для защиты от каскадных отказов. По hystrix рекомендую почитать medium.com/netflix-techblog/fault-tolerance-in-a-high-volume-distributed-system-91ab4faae74a
— Многое-многое другое…
Минимизация time-to-market означает, что мы должны иметь релизный цикл с короткими итерациями и возможность выпускать отдельные фичи независимо друг от друга. Т.е.:
— Быстро тестировать.
— Быстро выкатывать новые версии.
— Быстро обнаруживать и исправлять проблемы после выкатки.
— Разделить систему на много независимо поставляемых приложений.
Мы движемся в направлении микросервисной архитектуры, которая и позволяет реализовать все эти задачи.
Она хорошо подходит при масштабах Сбербанка. Только над фронт-офисными приложениями у нас работают сотни команд.
По микросервисам рекомендую изучить статью Фаулера: martinfowler.com/articles/microservices.html или ее перевод: habr.com/post/249183
Микросервисный подход отлично ложится и на новую организационную структуру, построенную на принципах agile.
В частности, этим летом централизованную эксплуатацию разнесли по agile-командам.
Тем самым, созданы предпосылки для построения devops-культуры, которая необходима для успешной эксплуатации микросервисов.
Важными моментами для независимого выпуска фич являются:
— Обратная совместимость на уровне API. Обеспечить ее помогают такие шаблоны проектирования, как Consumer Driven Contracts martinfowler.com/articles/consumerDrivenContracts.html
и Tolerant Reader martinfowler.com/bliki/TolerantReader.html
— Возможность включения/выключения отдельных фич (или старой и новой версий фичи) в рамках одного приложения. Тут помогает шаблон Feature Toggle (https://martinfowler.com/bliki/FeatureToggle.html).
Разумеется, помимо этого, есть огромный пласт работ, которые сделаны или делаются для обеспечения эксплуатации микросервисов:
— Внедрение контейнеризации. Сейчас пилотируется OpenShift.
— Devops pipelines.
— Автотесты, в том числе тесты API на совместимость.
— Разрабатывается собственный API gateway на основе nginx.
— Централизованное логирование с возможность находить логи в рамках одного запроса по correlation token.
— Различные механизмы защиты от отказов, например, квотирование в разрезе потребителей сервиса. Другой пример — аналог hystrix для защиты от каскадных отказов. По hystrix рекомендую почитать medium.com/netflix-techblog/fault-tolerance-in-a-high-volume-distributed-system-91ab4faae74a
— Многое-многое другое…
0
Приветствую!
К сожалению, очень редки посты от такой именитой в ИТ компании.
Что нового принес Давид Рафаловский? Как далеко продвинулся Сберджайл? Какова статистика по fail-проектам в Сбербанке и в дочке (Сбертех)? Есть ли разница? Вопросов много…
Будьте активнее!
К сожалению, очень редки посты от такой именитой в ИТ компании.
Что нового принес Давид Рафаловский? Как далеко продвинулся Сберджайл? Какова статистика по fail-проектам в Сбербанке и в дочке (Сбертех)? Есть ли разница? Вопросов много…
Будьте активнее!
+1
за последние 1,5 месяца вышло 15 постов. Но мы вас услышали, будем стараться. Что касается ваших вопросов, про Сберджайл рассказано, например, здесь: habr.com/company/sberbank/blog/350990
vc.ru/38179-agile-na-11-000-sotrudnikov
vc.ru/38179-agile-na-11-000-sotrudnikov
0
Пооффтоплю маленько. Я бы посоветовал проверять указываемые клиентами Сбербанка адреса электронной почты, чтобы не рассылать конфиденциальную информацию посторонним людям. А то странно, когда контора хвалится отказоустойчивостью своего фронт-офиса, но не может организовать элементарные вещи…
+1
неуместная шутка
+3
Давеча был в Дедовичах (Псковская область), дважды пробовал закинуть денег на телефон.
Безрезультатно
0
Sign up to leave a comment.
Секреты отказоустойчивости нашего фронт-офиса