Выступление Германа Оскаровича Грефа не осталось незамеченным не только среди политического и экономического истеблишмента, но и получило резонанс в ИТ-сообществе. Еще бы. «Agile, cloud-based, deep machine learning, artificial intelligence», – и все эти базворды не из уст айти-гика, а слова государственного деятеля, президента и председателя правления Сбербанка России. Думаю, что Герман Оскарович, конечно, не сам писал тезисы айтишной части своего выступления, а, как обычно, помогали эму в этом айти-советники.

Далее в посте цитаты из выступления по посту на Geektimes, вопросы, которые они у меня вызвали, мои ответы и гипотезы о том, что айти-советники хотели сказать и, наконец, брюзжание на тему об опасности революций.

Цитата: «В прошлом году мы сделали 27 000 изменений платформы. Для сравнения — 5 лет назад мы делали 600-800 изменений. В этом году мы сделаем 41 000 изменений. Если посмотреть на банки – мы в шоколаде, все в порядке. Если посмотреть на вот этих ребят всех – Amazon, Google и так далее, то Amazon делает 10 000 изменений своей платформы в день. 10 000 в день и 40 000 в год это несопоставимые вещи. Time to market – часы, и time to market – месяцы, это неконкурентоспособная история».

Вопрос: О чем свидетельствует число изменений платформы в единицу времени?

Ответ: Ни о чем, кроме производительности программистов.

Гипотеза: Численность сотрудников компании Amazon, примерно 100000 человек. Поскольку бизнес компании — продажа товаров и услуги через Интернет, а не производство ПО, то айтишники в ней — обслуга, и, полагаю, что они составляют не более 5% от общей численности. Итого, где-то, 5000 человек. Из них программистов, примерно, четверть, то есть, 1250 человек. Остальные менеджеры, аналитики, тестировщики и прочие админы. Считаем производительность.

Среднее количество изменений, переданных программистом в тестирование за рабочий день, = 10 000 изменений в день / 1 250 программистов = 8 изменений в день.

И это очень крутой конкурентный результат.

Асхат в своем блоге, ссылаясь на выступление на конференции, одного из директоров Амазона в 2011 году, говорит, что речь идет не об изменениях, а о деплоях в продакшн, то есть сколько раз за промежуток времени изменения попадают на сервера и становится доступным для конечных пользователей.

Не верю. Не Асхату, конечно, а директору. Даже, если мои оценки производительности программистов не завышены, то в продакшн каждые 10 секунд должны уходить в среднем не более чем по одному изменению. А смысл? А если изменений больше то, кто их кроме программистов делает.

Вопрос: Как связаны количество изменений и Time to market?

Ответ: Совсем никак. Потому, что Time to market определяется архитектурой системы и производственной технологией. Чем больше размазана бизнес-логика, чем больше связанность между модулями, тем больше времени потребуется на анализ, проектирование, разработку и тестирование. И в первую очередь — регрессионное. Чем более критичен и ответственен бизнес, тем тяжеловеснее технологические процессы и жестче регламенты. Иначе — «Фобос в грунт» и никакой agile от этого не спасет.

Цитата: «И мы для себя принимаем решение, что мы уходим в прорыв вообще, мы меняем целиком нашу платформу. Мы покупаем маленький пакет акций в российско-американской компании, которая выиграла тендер, который мы проводили, выиграла тендер у Oracle, IBM и так далее – у всех. Ее платформа (C_B: ошибка в источнике) Производительность ее платформы (C_B: цитата по видеозаписи) оказалась на порядок выше, ровно на порядок выше, чем у этих компаний. Шестьдесят программистов ее делают».

Вопрос: Почему новое решение названо платформой (как явствует из интернета, это In-Memory Data Fabric, от GridGain Systems, которая специализируется на In-Memory Computing)?

Ответ: Это не платформа, а in-memory база данных. В ней нет движка бизнес-процессов, решения класса ESB с автоматической диспетчеризацией и гарантированной доставкой, аналитической и отчетной платформы и многого чего еще.

Вопрос: А что конкретно сравнивали по производительности In-Memory Data Fabric с Oracle RDBMS и IBM DB2 или, все-таки, с сопоставимыми решениями Oracle TimesTen и SolidDB, приобретенной IBM.

Гипотеза: Очень надеюсь, что второе, а также, что не забыли еще одного из лидеров среди продуктов этого класса SAP HANA.

Вопрос: А почему выбор был сделан именно по производительности?

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

А теперь брюзжание.

Сбербанк затевает не одну, а сразу три революции: переписывание всей системы, переход на новые айти-технологии, повсеместное внедрение agile-процессов. То, что «это, конечно, колоссальный вызов» Греф, безусловно, прав. Но, с другой стороны, «проект без рисков – удел неудачников».

Не уверен, стоит ли сравнивать Сбербанк с Goolge, поскольку Google — это 2 миллиарда строчек кода. Думаю, если переписывать всю АИС Сбербанка, то это будет, где-то, 10 миллионов строчек исходного кода, включая автотесты. Но и это тоже серьезный вызов и наверное главная опасность, поскольку только 14% подобных масштабных разработок завершаются успешно, а 65% — успешно проваливаются (С. Макконнелл, «Сколько стоит программный проект», «Питер», 2007).

Средняя производительность хороших проектных команд при разработке ПО BSS — 40 протестированных и документированных SLOC в день на одного бойца, включая менеджеров, аналитиков, тестировщиков и прочих админов. Следовательно, суммарная трудоемкость разработки новой системы составит

10 000 000 SLOC/ (40 SLOC в день на человека * 21 день в месяц) = 12 000 чел.*мес.

И это оптимистичная оценка поскольку, среднеотраслевая производительность, согласно статистики COCOMO II, составляет всего 15 SLOC в день.

Не стоит рассчитывать, что 6 тысяч программистов Сбербанка, разработают эту систему за 2 месяца, поскольку, «девять беременных женщин не родят ребенка за месяц». Если оценить длительность проекта по формуле Барри Боэма, получим

Длительность [месяцы] = 2,5 * 12 000 ^ (1/3) = 60 месяцев = 5 лет

И это не один проект, а целая программа проектов.

Теперь про главные риски и про то, как им можно противодействовать.

1. Неточность и неполнота требований к существующей системе.
Закладывать на аналитику, примерно, в два раза больше трудозатрат, чем при создании системы с нуля, поскольку порой кроме декомпиляции исполнимого легаси-кода ничего не может помочь.

2. Получить еще более размазанную логику и более связанную модульность
Запланировать тщательное комплексное проектирование архитектуры, прототипирование и тестирование на соответствие нефункциональным требованиям. Причем, проектировать надо не ПО, а систему систем, в состав которой входит электротехническое оборудование, вычислительная инфраструктура и СХД, программное, телекоммуникационное и организационное обеспечение с учетом всех их разнообразных взаимосвязей и взаимозависимостей.

3.Нестабильность нового базового ПО.
Я с оптимизмом смотрю на новые технологии и верю в профессионализм программистов с российскими корнями, но знаю, что на разработку серьезного продукта, применимого в критическом бизнесе уходит десять лет. Я не нагуглил, какая по счету имеется в настоящее время стабильная версия ПО In-Memory Data Fabric, но хорошо помню, что первые десять лет, по словам самого Ларри Эллисона, клиенты требовали вернуть не деньги, но данные. А пригодная для критических применений версия базы данных была только 5.1. Поэтому стоит заложить дополнительное время и затраты на стабилизацию нового базового ПО.

4.Снижение производительности команды вследствие перехода на новое базовое ПО и производственные процессы.
По-старому нельзя, а по-новому еще не умеем. Следовательно необходимо учесть кривую обучения в планах.

5. «Ахиллес никогда не догонит черепаху».
Все известные мне попытки сразу заменить старую систему подобного масштаба на новую проваливались. Происходило это из-за неприемлемых затрат на параллельное внесение изменений в функциональные требования в старой и новой системе. Даже не советую про это думать. «Слона нельзя съесть целиком», поэтому его надо разрезать на подпроекты, которые можно реализовывать командой в 7-10 бойцов и в срок 6-10 месяцев. И по готовности заменять в промышленной эксплуатации старую функциональность на новую. Кстати, возможность такого подход это тоже одно из важных требований к проектированию архитектуры. Такой подход, примерно, удвоит трудоемкость разработки системы, поскольку потребует дополнительных усилий на интеграцию старой и новой системы, для обеспечения их мирного сосуществования. Но не должно повлиять на сроки, поскольку разработку и интеграцию можно вести параллельно.

ЗЫ. Безусловно, в ИТ сделать можно все, что не противоречит законам природы. Это вопрос только политической воли, денег и сроков.

Успехов!