6 октября 2021 г.
О пользе ошибок
Ошибки в ИТ носят особый характер. Например, если работаешь по гибким методологиям, то ошибки — это что-то наподобие маркера управленческой зрелости.
И заказчик, и исполнитель создают условия, при которых, если специалисты исполнителя ошиблись и пошли по ложному пути, они максимально оперативно говорят об этом своему руководству и заказчику. С другой стороны — сотрудники заказчика, стараясь найти оптимальные решения, готовы ошибаться, так как знают, что их за это не накажут.
Без череды проб и отбрасывания ненужных гипотез нельзя получить по настоящему прорывной результат: ошибки, как бы странно это ни звучало, в высоконагруженных веб-проектах обеспечивают инновации и лидерство.
Но такого рода ошибки возможны только тогда, когда между заказчиком и исполнителем есть доверие. При этом каждый из них уверен в своих силах по решению достаточно сложных управленческих и технологических задач. И одна из первых — заключить договор на работу по Agile или Scrum.
Многие заказчики избегают новых подходов. И их можно понять — корпоративная культура большинства крупных компаний не воспринимает скрамовскую гибкость в части отсутствия прямой связи между платежами и результатом. «Вечером деньги — утром стулья» — в Scrum не работает. Здесь другие алгоритмы и другие критерии успешности.
Победителей не судят
ИТ-директора крупных корпораций — осознают они это или нет — вышли на невидимую передовую бизнеса, который они представляют. Это в доковидное время, когда можно было довольствоваться офлайн-лидерством, они не торопились и соблюдали требования о бережливом — вплоть до рубля — расходовании бюджета. Сейчас все изменилось: с ИТ-руководителей спрашивают за скорость цифровой трансформации. Стремительность изменений стала самым ценным конкурентным преимуществом, на которое ориентируются собственники бизнеса.
Кто быстрее застолбит место на рынке, запустит свой продукт, тот быстрее начнет получать профит. Даже те отрасли, которым, казалось, не надо доказывать свое онлайн-превосходство — они лидеры в офлайн — стремительно переводят бизнес-процессы в цифру.
Изменилось время, изменились подходы — сейчас необходимо как можно быстрее тестировать гипотезы и запускать MVP (минимальные жизнеспособные продукты). А это приводит к росту себестоимости команд и неизбежному «расточительству»: тратить
Победителей, которые выдают на-гора результат, не судят. Но чтобы таковыми стать, приходится проделывать невероятные организационные кульбиты, так как корпоративные правила зачастую не дают возможность использовать гибкие подходы — Scrum, Agile, Kanban — без «упаковки» их в бюрократические процедуры, которые свойственны тому же Waterfall.
В итоге соединения старых и новых подходов внешне мы как исполнители применяем нечто похожее на Scaled Agile Framework. Сверху это формальный̆ проектный̆ подход — с комитетами, длинными цепочками согласований, а внизу работает команда разработчиков по Scrum. Но только так можно запустить Scrum, а с ним и скорость для решения задач с десятками неизвестных.
И опыт, сын ошибок трудных...
Специалисты RDN Group начали заниматься интеграцией̆ еще когда в нашей̆ стране не был распространен DevOps-подход и гибкие методологии. Мы делали нетипичные интеграции Битрикс24 с 1С. И, как все первые — ошибались.
Если обобщить, то все ошибки можно разделить на методические — неправильное взаимодействие, про которые в общих чертах я уже рассказал; и технические, о которые мы набили шишки.
Чаще всего ошибки при проектировании сложных высоконагруженных веб-проектов проистекают из особенностей̆ систем, которые используют заказчики. Даже если мы возьмем готовое решение, оно все равно потребует доработки: ведь системы заказчика уже выстроены под конкретные бизнес-процессы. Поэтому универсальность и гибкость, как, например, техническая поддержка фреймворком, куча баз данных, не приведут ни к чему кроме издержек в разработке и дальнейшей̆ поддержке проекта.
Упростить инфраструктуру, возможности масштабирования, сократить время на поддержку и модернизацию можно было бы за счет единообразия программной̆ и аппаратной̆ части.
Еще одна повторяющаяся ошибка — мониторингу в Highload уделяют не столько внимания, сколько он требует. Зачастую настраивается доступность системы через приложение и мониторинг, чтобы в случае возникновения ошибки можно было оперативно принять меры. А этого недостаточно.
В Highload кроме работоспособности сервисов и доступности инфраструктуры нужно отслеживать производительность, собирать метрики, которые отвечают за транзакции пользователей̆. Мы должны понимать, как и какой̆ узел нашей̆ системы работает, с какой̆ скоростью какие ошибки возникают — для этого нужно отладить мониторинг до состояния, когда система сама сообщает об ошибках, а мы уже предпринимаем действия.
Не упустите из виду кластеризацию — она решает вопрос как масштабирования, так и надежности нашего приложения. Она не заменяет резервного копирования, контроля ошибок, тестирования, но необходима и имеет в Highload ряд особенностей, которые надо в обязательном порядке учитывать.
Ну и, конечно, не витайте в облаках. У бизнеса существует мнение, что для повышения отказоустойчивости достаточно просто перенести свое приложение в облако, например в Яндекс, Гугл, Амазон и т. д. — это решает проблемы с издержками на содержание собственной̆ инфраструктуры, ее модернизацией, поддержкой, но это может оказаться и капканом. Например, многие облачные инфраструктуры используют уникальные интерфейсы, у них свои особенности по работе с дисковыми хранилищами. Если мы пишем приложение, т. е. создаем масштабируемость на базе Амазона, то миграция в Яндекс.Облако может влететь нам в копеечку, потребуется переписать ряд скриптов, технологических решений.
Также мы должны понимать, что если существует миграция, то появляются геополитические угрозы. Выбирать облако нужно ответственно, опираясь на ФЗ РФ о защите персональных данных.
Вместо послесловия
Вне зависимости от типологизации совершаемых ошибок мы всегда должны их честно признавать. Как внутри компании, так и перед заказчиком. Потому что не существует стандартных сложных высоконагруженных веб-проектов. Мы проходим через череду проб, гипотез и ошибок, создавая эксклюзивный̆ продукт под задачи конкретного заказчика. И самая большая ошибка — видеть в ошибках только ошибки.
Источник: Дмитрий Россихин, директор RDN Group
