Начиналось всё с системника в общаге МГУ и обычного хостинга, на котором размещалось наше расписание электричек, которое многие из вас видели. И перекладывания файлов по ночам, чтобы уложиться в лимиты нагрузки. Потом появились первые сервера. Они получали тройной трафик на майские, отчего сразу ложились. Точнее, мы не знаем, какой трафик они получали, потому что ложились именно на тройном от обычного.



Оглядываясь назад, могу сказать, что все действия по размещению с тех пор — это вынужденные ходы. И вот только сейчас на пятнадцатый год мы можем настраивать инфраструктуру так, как нужно нам.

Сейчас мы стоим в 4 физически разных ЦОДах, соединённых кольцом тёмной оптики, размещая там 5 независимых пулов ресурсов. И так получилось, что если в одну из кроссовых попадёт метеорит, то у нас тут же отвалится 3 этих пула, а оставшиеся два не потянут нагрузку. Поэтому мы занялись полной ребалансировкой, чтобы навести порядок.

«Это должно быть сделано еще вчера», «Протестируйте как-нибудь быстренько», «Время от начала разработки до выкладки на продакшн должно быть минимальным, а если возможно — еще меньше» — наверное, многим знакомы подобные цитаты. И покуда мы (тестировщики) — одно из последних звеньев в цепочке разработки, именно нам чаще всего приходится балансировать между скоростью выхода фич и их качеством.

В данной статье хочу поделиться тем, как мы в нашей компании применяем успешные практики из Lean Startup (несмотря на то, что многие наши проекты вполне сформировались и устоялись), с какими проблемами сталкиваются тестировщики при использовании данной методологии и как мы с этими трудностями справляемся.

Пара слов о себе: я тестировщик, имела опыт работы в проектах разного масштаба, была единственным тестировщиком на проекте и работала в командах, в которых использовались разные подходы и методологии. По моему опыту, работать по Lean Startup — это круто, но тут есть и подводные камни для тестирования, о которых неплохо знать заранее.