С 2010 года мы развиваем сервис для организации совместной работы и управления процессами.
В нашей системе Pyrus в настоящее время работают тысячи организаций и десятки тысяч пользователей.
За последние 4 года мы накопили хороший опыт в обеспечении надежности и хотим поделиться им с вами.
1. Все может сломаться
Стараемся подстелить солому везде, где это возможно.Все серверы баз данных на 100% зеркалированы.
В дата-центрах регламентные работы проводятся по 2-3 часа, в течение этого времени наш сервис не должен прерывать работу.
Поэтому зеркала расположены в разных дата-центрах и даже в разных странах.
Кроме того, на серверах необходимо регулярно устанавливать обновления безопасности, которые иногда требуют перезагрузки.
В таких случаях на помощь приходит горячее переключение на резервный сервер.
На серверах есть RAID, резервное копирование делаем ежедневно.
У нас есть несколько серверов приложений, это обеспечивает масштабируемость и позволяет обновлять их один за другим, не прерывая обслуживание.
Для балансировки нагрузки мы используем механизм циклического DNS. Мы предположили, что DNS — самая надежная система в Интернете, ведь без нее не откроется ни один сайт. Однако здесь нас ждал сюрприз.
Мы разместили доменную зону у крупного регистратора Register.com, который обслуживает более 3 миллионов доменов.
Как и ожидалось, у нас есть 2 независимых сервера доменных имен (nameserver), что защищает от сбоя одного из них.
Однажды утром они оба отказались.
Консоль управления Register.com была недоступна.
В Твиттере стали появляться робкие жалобы пользователей, которые через час сменились лавинообразным потоком криков, плача, причитаний и обещаний немедленно покинуть этого провайдера.
Как только он снова включит сервер.
С тех пор мы перенесли нашу доменную зону на Amazon, которая предоставляет 4 сервера доменных имен, расположенных в разных корневых зонах Интернета: .
com, .
net, .
org, .
uk. Это обеспечивает дополнительный уровень надежности: даже если вся доменная зона .
com по каким-то причинам будет недоступна в DNS, клиенты все равно смогут работать с нашим сервисом.
Заключение: проектируйте систему, зная, что рано или поздно любой компонент выйдет из строя.
Помните Мерфи: если есть шанс, что может случиться что-то плохое, то оно произойдет.
2. Вы не знаете, где ваше приложение является узким местом
По мере роста нагрузки мы постоянно делаем 2 вещи: покупаем память (ОЗУ) и оптимизируем приложение.Но как узнать, какая функция в приложении работает недостаточно быстро? По синтетическим измерениям в тестах на машине разработчика судить сложно.
Запустить профилировщик на рабочем сервере практически невозможно — это добавляет слишком много накладных расходов и сервис начинает тормозить.
Приходится вставлять в код контрольные точки и оценивать скорость работы приложения по времени выполнения программы между ними.
Итак, мы выяснили, что 1/3 процессорного времени тратится на.
сериализацию: упаковку структур данных в строки JSON. Изучив альтернативные библиотеки сериализации, мы приняли непопулярное решение: написать свою.
Внедрение под наши конкретные задачи сработало в 2 раза быстрее, чем самое быстрое альтернативное решение, доступное на рынке.
Кстати, многие ошибочно полагают, что шифрование потребляет много ресурсов процессора.
Раньше действительно этот процесс мог «съедать» до 20% ресурсов процессора.
Однако, начиная с архитектуры Westmere, выпущенной в январе 2010 года, команды алгоритма шифрования AES включены в набор команд процессоров Intel. Поэтому переход с HTTP на HTTPS практически не меняет нагрузку на процессор.
Заключение: Не оптимизируйте преждевременно.
Без проведения точных измерений ваши предположения о том, что вам нужно ускорить, вероятно, будут неверными.
3. Тестируйте все
Однажды нам нужно было изменить структуру таблицы в базе данных.Эта процедура требует остановки службы, поэтому мы запланировали ее на наименее загруженное время — ночь выходного дня.
Наши тесты показали время выполнения менее одной минуты.
Мы остановили службу и запустили процедуру на рабочем сервере, но она не завершила работу ни через одну, ни через десять минут. Оказалось, что процедура в некоторых случаях начинает перестраивать кластерный индекс таблицы, размер которой на тот момент составлял около 1ТБ.
Мы этого не заметили, поскольку тестировали на маленьком столе.
Пришлось запускать службу, не дожидаясь завершения процедуры.
К счастью для нас, все основные функции работали корректно, хотя и несколько медленнее обычного, за исключением прикрепления файлов к задачам.
Процедура завершила свою работу через пару часов и 100% работоспособность была восстановлена.
Заключение: тестировать все изменения на объемах данных, близких к боевым.
Мы запускаем около 500 автоматических тестов для каждой сборки приложения, чтобы гарантировать отсутствие фатальных ошибок.
4. Скорость тестирования должна быть высокой
Мы выпускаем обновления приложения каждую неделю.Пару раз в год, несмотря на тестирование, в релиз закрадывается ошибка, маленькая, но неприятная.
Обычно такие ошибки обнаруживаются в течение 10 минут после релиза.
В таких случаях мы выпускаем исправление.
Никто не любит откатывать релизы, но иногда это необходимо.
Исправление должно быть сделано быстро; мы часто обнаруживаем причину ошибки в течение получаса.
Но чтобы релиз дошел до производственных серверов, исходный код должен пройти автосборку и автоматические тесты.
Наши 500 тестов занимают более 20 минут, что довольно быстро, но мы планируем еще больше сократить это время за счет большего распараллеливания.
При медленном тестировании мы не смогли бы так быстро исправлять ошибки, а без тестирования вообще количество ошибок было бы выше.
Заключение: Не экономьте на ресурсах разработчиков.
Покупайте производительные сервера для автоматизированных тестов, количество которых будет постоянно расти.
5. Необходимо использовать все функции продукта.
Хорошие продукты требуют множества итераций.
В продукт постоянно добавляются новые функции, но редко используемые функции приходится вырезать.
Они не несут никакой пользы: тратят время разработчиков на их обслуживание и занимают дополнительное место на экране.
Хороший садовод каждую весну подрезает молодые побеги и формирует правильную, здоровую и красивую крону дерева.
Есть ли в вашем продукте функции, которыми никто не пользуется? Мы в Пайрусе не знаем никого подобного.
Опытным путем мы выработали правило: каждую функцию используют не менее 2% пользователей.
Это означает, что когда мы отключаем какую-то функцию, она не нравится десяткам или сотням людей.
Мы всегда предлагаем другой способ сделать то же самое, но привычка сильнее.
Заключение: развитие требует некоторых жертв.
Представьте себе, скольким людям не нравятся любые изменения в продуктах Google и Microsoft. Теги: #управление задачами #управление проектами #ошибки и грабли #советы #личный опыт #тестирование ИТ-систем
-
Жолио-Кюри, Ирен
19 Oct, 24 -
Берлинский Суд Запретил Такси Uber
19 Oct, 24 -
Истоки Мотивации В Agile И Scrum-Менеджменте
19 Oct, 24 -
Акция На Обновление От Toshiba
19 Oct, 24 -
Кто Принимает Окончательное Решение По Digg?
19 Oct, 24
