Выступление Германа Оскаровича Грефа не осталась незамеченным не только среди политического и экономического истеблишмента, но и получило резонанс в ИТ-сообществе. Еще бы. «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 человек. Остальные менеджеры, аналитики, тестировщики и прочие админы. Считаем производительность.
Среднее количество изменений, переданных программистом в тестирование за рабочий день, = 10000 измен в день / 1250 программистов = 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 месяцев. И по готовности заменять в промышленной эксплуатации старый функционал на новый. Кстати, возможность такого подход это тоже одно из важных требований к проектированию архитектуры. Такой подход, примерно, удвоит трудоемкость разработки системы, поскольку потребует дополнительных усилий на интеграцию старой и новой системы, для обеспечения их мирного сосуществования. Но не должно повлиять на сроки, поскольку разработку и интеграцию можно вести параллельно.
ЗЫ. Безусловно, в ИТ сделать можно все, что не противоречит законам природы. Это вопрос только политической воли, денег и сроков.
Успехов!
Автор: craft_brother
