Это что-то типа служебной записки руководству компании после очередного совещания на тему архитектуры системы и развития вообще.
Автор (я) — один из разработчиков.
Контора — интернет-магазин.
----------------------
По архитектуре:
Архитектура не нуждается в оперативном изменении: за последние три-шесть месяцев подавляющее большинство серьезных проблем было вызвано вмешательством человека; все проблемы были оперативно решены.
Любые изменения архитектуры должны быть решением какой-либо проблемы, а не желанием почесать руки. Появление новых требований, новых бизнес-процессов относим к проблемам, и решаем по мере появления.
Т.о. приоритетным является вопрос своевременного планирования новых бизнес-процессов (а равно, и изменение существующих). Иными словами, чем раньше и точнее будет озвучено ТЗ, тем качественнее оно будет реализовано.
Желание разработчиков сделать все по фен-шую необходимо поощрять, но ориентироваться нужно на финансовый результат, а не на тщеславие и желание программистов заниматься творчеством. Однако, необходимо осознавать, что программисты — живые люди: они тоже хотят любить и быть любимыми.
Повседневный рефакторинг-оптимизация не отрицает серьезных изменений архитектуры в целом; вопрос заключается именно в выделении времени на анализ уже существующего кода и решений.
Про вероятное увеличение нагрузки:
Разговоры с рисованием квадратиков и связей между ними имеют малую ценность: как показывает практика, сломаться может все. Например, переписанный на xxx (исключительно ради повышения надежности) xxx не сломался, но перестал работать из-за зависшей виртуальной машины. Безусловно, необходимо понимать, что если бы xxx не переписали, проблемы появились еще раньше.
Т.о. первоочередное значение приобретает тестирование — как системы в целом, так и отдельных ее узлов. Приоритет необходимо отдавать критически важным узлам (неработающий xxx или неработающий xxx — разница очевидна).
Для организации (стресс-) тестирования существуют готовые решения (вплоть до платных сервисов), но ничто не мешает реализовать тестирование самостоятельно: все сотрудники xxx, услышав лай караульной собаки, создают по десять-двадцать-тридцать заказов; it-отдел выясняет: где именно возникли проблемы.
Полезными могут оказаться следующие действия:
а. на xxx определить наиболее тяжелые блоки; в случае повышения нагрузки эти блоки можно отключить, если это не приведет к критической потере функционала системы (например, блоки xxx, xxx, и т.д.) Критически важные блоки: каталог товаров, регистрация юзеров, покупка товаров, создание и оформление заказа. Очевидным является: чтобы измерить что-то, предварительно нужно создать инструменты для измерения.
б. создание "легковесной" копии сайта, на которую можно оперативно переключиться. На этой копии сайта оставить только критически важные вещи (см. выше), все остальное (частично — даже БД) — обнулить; из всего каталога товаров оставить только те, которые можно купить.
С другой стороны: опыт показывает, что в большинстве случаев нагрузка повышается НЕ лавинообразно, оставляя it-отделу время для продумывания и принятия мер противодействия, поэтому "сервер в Австрии на случай нападения марсиан" — излишество.
Про DDOS-атаки, упомянутые на совещании:
Вопросы решения DDOS-атак обычно возлагаются на хостеров (впрочем, в большинстве случаев, безосновательно); необходимо привлечь xxx, чтобы он обсудил этот вопрос с нашим хостером. На основании моих личных знаний и опыта: если сильно захотят, нас заддосят в любом случае, вне зависимости от принятых нами мер.
Глобально:
It-разработчики — это: реализаторы, механики, слесари, технари. Большая часть их рац-предложений сводится к "этот mysql запрос можно оптимизировать", роль программистов при обсуждении финансовой выгоды бизнес-процессов — минимальна; компания может потратить время программистов более выгодно. Для придумывания маркетологических акций существуют люди со специальным образованием.
Разработчикам требуется время и на обдумывание реализации ТЗ, и на реализацию ТЗ. Еще больше времени требуется в случаях: "да, в ТЗ этого не было, но это подразумевалось", "да, изначально в ТЗ этого не было, но теперь появилось".
Меня лично прошу освободить от участия в совещаниях-обсуждениях "нехай кладовщики по складу на роликах катаюццо" и "юридическая организация отделений мега-корпорации в регионах" — мне это неинтересно.
Итоги, выводы:
— оперативные решения и изменения не нужны, работаем в обычном темпе
— любые изменения архитектуры — ответ на новые бизнес-требования: нет новых требований — изменения не нужны
— осознаем важность своевременного и точного объяснения ТЗ
— занимаемся разработкой инструментов диагностики (как ручной, так и автоматической)
— определяем тяжелые блоки
— проводим (стресс-) тестирования
