Pull to refresh

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

Sign up to leave a comment.