Комментарии 8
Сейчас в планах — минимизировать time-to-market нашей единой системы
Добрый день, какие шаги для этого будут сделаны? Давно слышу о минимизации, есть ли результаты?
Добрый день!
Минимизация 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
— Многое-многое другое…
Приветствую!
К сожалению, очень редки посты от такой именитой в ИТ компании.
Что нового принес Давид Рафаловский? Как далеко продвинулся Сберджайл? Какова статистика по fail-проектам в Сбербанке и в дочке (Сбертех)? Есть ли разница? Вопросов много…
Будьте активнее!
К сожалению, очень редки посты от такой именитой в ИТ компании.
Что нового принес Давид Рафаловский? Как далеко продвинулся Сберджайл? Какова статистика по fail-проектам в Сбербанке и в дочке (Сбертех)? Есть ли разница? Вопросов много…
Будьте активнее!
за последние 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
Пооффтоплю маленько. Я бы посоветовал проверять указываемые клиентами Сбербанка адреса электронной почты, чтобы не рассылать конфиденциальную информацию посторонним людям. А то странно, когда контора хвалится отказоустойчивостью своего фронт-офиса, но не может организовать элементарные вещи…
неуместная шутка
Давеча был в Дедовичах (Псковская область), дважды пробовал закинуть денег на телефон.
Безрезультатно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Секреты отказоустойчивости нашего фронт-офиса