Пользователь просто переходит дорогу.
Разработчик посмотрит налево, прежде чем перейти.
Техлид команды (в моей системе отсчёта — это архитектор) посмотрит и налево, и направо.
Матёрый архитектор ещё и вверх посмотрит, под ноги глянет, дорожные знаки проверит и пользователей до и после перехода пересчитает.
По моим ощущениям, иногда без должного внимания остаются вопросы, которые могут заблокировать и даже похоронить весь проект.
Команды часто так сосредоточены на том, чтобы написать свою идеальную систему, что не замечают глобальных рисков.
Вот 10 моментов, которые чаще всего откладывают “на потом”, т.к. нужно в моменте решать 100500 других неотложных и важных задач:
1. "Зачем вам еще 10 виртуалок?!.."
Самостоятельно уточняйте и формулируйте требования к железу.
Пусть даже сайзингом занимается кто-то ещё — у вас должен быть свой список оборудования, ресурсов, цифры, с которыми система должна работать.
Бывает, Заказчик даже примерно не ожидает выделения таких мощностей, держа в голове: "Раньше это было 2 ВМ, теперь, ну пусть будет 4..."
Если знать заранее об этих ожиданиях, то можно впихнуть систему и в ограниченные ресурсы, но про цену таких решений стоит договориться на берегу и зафиксировать всё как ограничения системы. Либо дать Заказчику время спланировать нормальную закупку.
А ещё бывает, что внезапно появившийся "эффективный менеджер" заменяет SSD на HDD ("Больше и дешевле! Я молодец!").
И теперь ваша СУБД скрипит дисками так, что этот звук вы явственно слышите по ночам вместе с девопсами. К тому же многие консенсусные системы (zookeeper, etcd) такое медленное вообще не любят и будут "радовать" вас fsync timeout, порождая нештатные ситуации на ровном месте. Постарайтесь держать руку на пульсе этого процесса расчёта-заказа-закупки на всех его поворотах.
2. "А кто это всё будет поддерживать?"
Как можно раньше узнайте (или заставьте узнать), кто и как будет поддерживать эксплуатацию (поддержка, девопсы).
Классический пример: отличный продукт в микросервисном исполнении, а у Заказчиков нет и не будет специалистов по куберу.
Микросервисы без кубера — это не только деньги на ветер, но и хронический недосып всех участников, увольнение админов и девопсов, вынужденных "держать на руках" всё это богатство.
Нет кубера? Упрощайте систему, иначе она вас сожрёт.
3. "Для всех у нас таймаут в 15 секунд на запрос"
Если у Заказчика уже есть кластер СУБД (или других систем), на который нужно будет залезть, — обязательно добейтесь наличия аналога на тестовом контуре с учётом обещанной свободной мощности под вашу систему.
Я даже не про экстремальные случаи, когда тестили на PostgreSQL, а заехали в Greenplum, а про варианты, когда на проде выделяют 50 коннектов, а тестились и нагружались на 500. Или когда между приложением и СУБД лежит layer7 proxy с настройками, за которые отвечает кто-то мегаважный, и, чтобы его убедить, что у вас другая система, нужно время.
4. Сеть — тёмная материя IT
К сожалению, не попробовав в бою этот апельсин, невозможно заранее сказать, хорош он или нет.
Сетевые сбои — частый спутник проблем в нагруженных системах: принудительные разрывы соединений, которых вы не ожидаете, валящийся по таймауту обратный резолв айпи в имена при прописанном, но недоступном днс и прочая магия, все варианты которой, пока не попробуешь, не узнаешь.
Проектируйте систему, учитывая наличие гремлинов с доступом к сетевым маршрутизаторам.
Уменьшить риск можно, если нагрузочный контур живёт в той же сети и по тем же правилам, что и прод (это не всегда возможно).
Можно подстраховаться (красивое — митигировать риск) — заранее обеспечьте наличие контакта с сетевыми экспертами, имеющими нужные доступы и полномочия. Это прямо +100 к внедрениям.
5. Ваша заявка на ВМ успешно зарегистрирована. Ожидайте ответ в течение 7 рабочих дней. Не забудьте приложить резолюцию финансового отдела и подпись технического директора.
Озаботьтесь ресурсами под девелоперские и тестовые стенды заранее. Если есть возможность включить в команду постоянных девопсов — обязательно делайте это.
Для команды не должно быть проблемой что-то развернуть и проверить. Это должна быть понятная и прозрачная для всех история.
Плохо — когда есть маленькое зерно сомнения, но его отметают, потому что "разворачивать ещё один контур — сложно, заявки, морока".
А ещё девопсы, которые с вами с самого первого контура, — это неоценимый ресурс на запуске. Объяснить все нюансы системы новому специалисту, даже с документацией, — это время. Как говорил один мой преподаватель: "Нельзя выпить напиток знаний залпом".
6. Документация? Это где-то у техписов …
То, что рабочая документация нужна, актуальна и вообще must have, кажется, написано раз примерно миллион. Взять отдельного, слабо погруженного в проект аналитика или техписа, чтобы он там сбоку что-то писал — худший вариант.
Но писать документацию "в стол" (пока она не понадобилась) команде психологически сложно. Психологическое насилие над командой не рассматриваем, поэтому на небольших проектах можно составлять техдоки самостоятельно.
Если проект большой, то можно выстроить производственный процесс так, что разработчик пишет только(!) по техпроекту, тестировщик тестирует только(!) по техпроекту и никак иначе. Тикеты — маркеры изменений техпроекта.
7. Кто помнит, а почему мы требуем <какое-то сильно мешающее ограничение>?
Фиксируйте важные моменты, какими бы очевидными или малозначительными они ни казались сейчас.
Со временем очевидность падает, а значимость растёт.
Поверьте, рано или поздно очевидное сейчас всем знание, что avro-c нужно пересобирать именно на CentOS 7 из неофициального репозитория, забудется. И еще забудется причина, почему так. И тогда поиск причины неработоспособности потребует литров кофе и тонн часов специалистов.
8. Мы вообще не это хотели!
И снова про пипл-менеджмент. Будущих пользователей нужно уметь готовить. И Заказчиков тоже. Очень плохо, когда знакомство с системой происходит на сдаче проекта или уже после её запуска. Находите силы и время рассказать и показать систему ключевым пользователям, Заказчику и техническим специалистам Заказчика после каждого более-менее значимого релиза. Встречный “поток информации”, особенно поначалу, может ошеломить. К следующему релизу/показу выберите несколько проблем, которые были озвучены прошлый раз, и покажите их решёнными. Это создаст предпосылки для дальнейшего конструктивного взаимодействия.
9. Миграция данных: "А у нас в старой системе было всё точно!"
Импорт данных из legacy — большая лотерея. Заказчик почти всегда на 100% уверен, что в старой системе данные идеальны. Но это всегда не так.
Время на поиск нестыковок может оказаться существенно больше нуля. Новые или даже отрефакторенные бизнес-алгоритмы могут неожиданно для всех выявить скрытые нестыковки, приписки, левые списания и т.п. неточности в данных — будьте вместе с Заказчиком к этому готовы. Как вариант, заранее объявите о широкой амнистии за кривые данные в прошлом. В противном случае, можно вместо конструктива нарваться на дезинформацию в попытке снять с себя ответственность, а это снова безумные (еще и бесцельные по сути) траты невосполнимого ресурса — времени.
10. "Вы должны сдать всё по ТЗ + всё, что успели пообещать"
Помните: если вы пообещали Заказчику сделать что-то лучше/больше/красивее, чем в ТЗ, — вам придётся сдать и обещанное, и то, что написано в документах.
Это не потому, что кто-то плохой, — просто таковы законы физики.
<тут должна быть какая-то завершающая мотивирующая фраза, не забыть вписать>
С уважением, но без телеграм канала :-)
