Вы — ProductOwner и отвечаете за группу веб-проектов. Когда сайты висят, недоступны или Клиентам выводится отладочная информация типа «Exception in object COrderController constructor… » — вам начинают звонить на мобильный, писать в твиттер и т.п.:
Еще веселее, когда вас дергают… вечером за ужином, в иное время во время исполнения супружеских обязанностей, в отпуске :-)
Разберем популярные кейсы, ключевые принципы обеспечения доступности веб-проектов и попытаемся выстроить чеклист «Безмятежного отпуска».
По-хорошему, нужно узнать о проблемах с веб-проектом РАНЬШЕ, чем на нее нарвался Пользователь сайта — и постараться исправить ситуацию. Хуже, когда о проблеме с вашим веб-проектом узнали десятки (тысяч) Пользователей, ваш руководитель, и успели даже обсудить «висение» в твиттере, сделать скриншот ошибки.
Часто происходит следующим образом:
Спасибо что сказали, сейчас апач перегружу... — т.е. пока не толкнешь в з..., никто ничего не сделает.
В результате простой веб-проекта составляет до десятков минут. Придется объясняться перед Пользователями, почему ваш крутой, высокотехнологичный веб-проект с ценными данными Клиентов — висел.
Есть отличный недорогой бизнес-процесс, позволяющий реагировать ПРОАКТИВНО. Поступаем так:
В данной точке мы можем надеяться, что о проблеме с вашим веб-проектом раньше или одновременно с Клиентами ТОЧНО УЗНАЕТ кто-то из службы системного администрирования и отреагирует В ЛЮБОЕ ВРЕМЯ.
В серьезных организациях для решения задачи оперативного реагирования можно попробовать согласовать с IT-службой «договор» об SLA, куда включить вышеуказанные задачи.
Рекомендую размещать машину мониторинга в другом датацентре — проследите. Если, как это часто бывает с отечественным хостингом (да и, как помним, в амазоне недавно тоже жестко «упал» один датацентр, где были наши машины), датацентр обесточится на несколько часов, то также отключится и наша машина мониторинга и никто внутри компании ничего не узнает, если инцидент произойдет на выходных :-)
Наверняка ваш веб-проект предоставляет Клиентам различные сервисы: отправка ключей, почтовых уведомлений по заказам, загрузку файлов и т.п. — эти сервисы тоже нужно включить в систему мониторинга. «Морда» веб-сайта может открываться, а вот загрузка файлов Клиентами в персональном разделе — не работать.
Поэтому требуем наличия постоянного мониторинга N сервисов нашего веб-проекта и надеемся, что получив уведомление «Сервис обработки заказов — не работает» мы узнали о проблеме сразу и ее решением уже начали заниматься ответственные.
Часто веб-проекты ломаются… постепенно. Уменьшилось место на диске сервера, перестали работать внутренние службы, отвечающие за резервирование и работу под нагрузкой — никто на это не отреагировал, а можно было…
Поэтому важно проследить, чтобы автоматический мониторинг проверял не только доступность ваших сайтов, но и работоспособность серверов, служб, баз данных и прочая и прочая. Полезно убедиться что служба системного администрирования делает это или начнет этим заниматься системно.
Опять-таки, для решения данной задачи используется бесплатный софт, который можно настроить достаточно быстро.
В результате мы надеемся, что некоторые отказы, влияющие косвенно на работоспособность веб-проектов, постоянно мониторятся, исправляются и не накапливаются до критической массы: проверяется «железо серверов», «здоровье» жестких дисков, сетевых маршрутизаторов и т.п.
Жуткий по своему цинизму, но распространенный кейс — разработчики вносят изменения в код веб-проекта прямо на «боевых» серверах, часто ломая функционал проекта в течение дня, удаляя (конечно случайно) страницы сайта и данные…
Разработчикам так проще всего — зашел и поправил/сломал и сразу виден результат и разработчику и Клиенту :-)
Как боремся с этим кошмаром:
Если разработчики просят у вас ресурсов на создание подсистемы внутреннего автоматизированного тестирования кода (примерно из этой вселенной также технология «непрерывной интеграции» — ContinuosIntegration) и команде можно доверять — пойдите навстречу. Этим вы снизите риск разрушения проекта в местах A,B,C после внесения изменений в функционал D.
В последнее время крутится модная байка, что веб-проекты находятся перманентно в сыром состоянии (beta) и это не страшно, что баги недоделанного и быстро введенного в эксплуатацию функционала находят Клиенты и не нужно держать группы тестировщиков — на самом деле, если письма от Клиентов о потере заказов и проблемах разбирать не вам — … :-)
Ваши веб-проекты «живут» на серверах, которые, скорее всего находятся в одном, «очень надежном» датацентре. К сожалению, датацентры ломаются — в них бьет молния, дядя Вася на экскаваторе обрывает кабели питания, сходит с ума уборщица и обливает водой сервера и т.п. — в общем ваши веб-проекты могут стать недоступными на время от нескольких часов до нескольких дней.
Если вы готовы пережить такое — читайте следующую главу. Неплохо работает следующая схема, позволяющая с минимальным временем простоя (можно добиться простоя в несколько минут, если постараться) пережить крах датацентра:
Элегантное и более простое решение данной задачи «быстрой миграции между ДЦ» предоставляет амазон. Датацентры там соединены высокоскоростными магистралями и «поднять» машины в другом датацентре, имея под рукой данные из свежих снэпшотов, можно за минуты!
Да, конечно все знают, что нужно делать резервное копирование данных веб-проекта. Скорее всего его делают… А вы пробовали их восстанавливать? :-) А знаете, что данные могут не восстановить по причине «испорченности» архивных копий?
Для борьбы с безответственностью и некачественной организацией резервного копирования полезно согласовать с it-подразделением план проведения «учений по восстановлению» — при котором, например, раз в месяц, проводится тестовое восстановление на отдельной машине ваших веб-проектов.
Еще лучше, включить в созданную нами систему мониторинга несколько тестов, которые «выбьют» если по какой либо причине резервные копии не будут сделаны либо не смогут быть прочитанными при восстановлении.
А сломать процесс резервного копирования, при высоком уровне раздолбайства профильных специалистов — легко и я лично на практике сталкивался с ситуацией, когда все думают что резервные копии делаются, а на деле — диск переполнился давно :-)
Любопытно поинтересоваться у it-службы: «А сколько времени будет восстанавливаться веб-проект из резервной копии в случае потери данных или аварии в датацентре?» Технически, при организации репликации (см. выше), можно обеспечить это за минуты (либо десятки минут). Однако можно услышать и такой ответ: «Данные восстановим суточной давности, а база данных будет заливаться из резервной копии часа 3» :-). Будьте бдительны.
При желании и определенной напористости можно довольно быстро настроить бизнес-процесс мониторинга и восстановления вверенных вам веб-проектов. Особенно если вы разместитесь в облаке. Техническая возможность… перманентного творческого наслаждения ProductOwner — имеется :-)
- топ-менеджер (или генеральный)
- коллеги, некоторые злорадствуя
- наши уважаемые Клиенты
Еще веселее, когда вас дергают… вечером за ужином, в иное время во время исполнения супружеских обязанностей, в отпуске :-)
Разберем популярные кейсы, ключевые принципы обеспечения доступности веб-проектов и попытаемся выстроить чеклист «Безмятежного отпуска».
Сокращаем время реагирования
По-хорошему, нужно узнать о проблемах с веб-проектом РАНЬШЕ, чем на нее нарвался Пользователь сайта — и постараться исправить ситуацию. Хуже, когда о проблеме с вашим веб-проектом узнали десятки (тысяч) Пользователей, ваш руководитель, и успели даже обсудить «висение» в твиттере, сделать скриншот ошибки.
Часто происходит следующим образом:
- сайты висят, несколько минут или больше
- Клиенты пишут/звонят вам и коллегам, в т.ч. в твиттер компании
- вы пишете сисадмину или в службу системного администрирования
- сисадмин говорит, что перезагрузит апач, после чего веб-проекты снова доступны
Спасибо что сказали, сейчас апач перегружу... — т.е. пока не толкнешь в з..., никто ничего не сделает.
В результате простой веб-проекта составляет до десятков минут. Придется объясняться перед Пользователями, почему ваш крутой, высокотехнологичный веб-проект с ценными данными Клиентов — висел.
Есть отличный недорогой бизнес-процесс, позволяющий реагировать ПРОАКТИВНО. Поступаем так:
- Договариваемся со службой системного администрирования настроить автоматизированный мониторинг ваших веб-проектов. Для этого существует немало бесплатного эффективного софта. Мы пользуемся nagios, многие используют zabbix и др. Настроить подобный софт — несколько часов. Что тестировать? Самый простой кейс: время загрузки страницы вашего веб-проекта и наличие на ней уникальной сигнатуры, например, номера телефона в футере.
- «Кто-то» должен среагировать в случае уведомления о проблеме от системы мониторинга. Если «кто-то» обедает или курит на полчаса, веб-проекты будут висеть эти полчаса. Очень помогает настройка отправки сисадминам смс на мобильники. На mail.ru, правда с ограничениями, можно отправлять смс-ки c вашего почтового ящика беспатно, но не чаще раз в полчаса. Если купить подписку на сервис рассылки смс, то они будут доставляться быстрее и без ограничений. Настроить процесс отправки системой мониторинга смс на мобильные сисадминам — минут 30. Если не дают добро на сервис отправки смс, можно, как минимум, заставить систему мониторинга делать почтовую рассылку всем сисадминам, вам и вашим коллегам — можно надеяться, что кто-нить из сисадминов будет на рабочем месте и отреагирует.
- «Кто-то» должен среагировать на проблему с вашим веб-проектом… на выходных, ночью, в праздники (например, в первых числах января). Нередко сталкивался со случаями, когда о висении веб-проектов на выходных или новогодние праздники узнавали… не сразу, а через несколько часов или дней. Просто никого из сисадминов не было на работе :-) В этом случае можно поступить так — договориться со службой техподдержки об организации дежурств во вне рабочее время — в это случае будет «кто-то», кто сможет и, главное, должен среагировать.
В данной точке мы можем надеяться, что о проблеме с вашим веб-проектом раньше или одновременно с Клиентами ТОЧНО УЗНАЕТ кто-то из службы системного администрирования и отреагирует В ЛЮБОЕ ВРЕМЯ.
В серьезных организациях для решения задачи оперативного реагирования можно попробовать согласовать с IT-службой «договор» об SLA, куда включить вышеуказанные задачи.
Рекомендую размещать машину мониторинга в другом датацентре — проследите. Если, как это часто бывает с отечественным хостингом (да и, как помним, в амазоне недавно тоже жестко «упал» один датацентр, где были наши машины), датацентр обесточится на несколько часов, то также отключится и наша машина мониторинга и никто внутри компании ничего не узнает, если инцидент произойдет на выходных :-)
Проактивный мониторинг — снаружи
Наверняка ваш веб-проект предоставляет Клиентам различные сервисы: отправка ключей, почтовых уведомлений по заказам, загрузку файлов и т.п. — эти сервисы тоже нужно включить в систему мониторинга. «Морда» веб-сайта может открываться, а вот загрузка файлов Клиентами в персональном разделе — не работать.
Поэтому требуем наличия постоянного мониторинга N сервисов нашего веб-проекта и надеемся, что получив уведомление «Сервис обработки заказов — не работает» мы узнали о проблеме сразу и ее решением уже начали заниматься ответственные.
Проактивный мониторинг — изнутри
Часто веб-проекты ломаются… постепенно. Уменьшилось место на диске сервера, перестали работать внутренние службы, отвечающие за резервирование и работу под нагрузкой — никто на это не отреагировал, а можно было…
Поэтому важно проследить, чтобы автоматический мониторинг проверял не только доступность ваших сайтов, но и работоспособность серверов, служб, баз данных и прочая и прочая. Полезно убедиться что служба системного администрирования делает это или начнет этим заниматься системно.
Опять-таки, для решения данной задачи используется бесплатный софт, который можно настроить достаточно быстро.
В результате мы надеемся, что некоторые отказы, влияющие косвенно на работоспособность веб-проектов, постоянно мониторятся, исправляются и не накапливаются до критической массы: проверяется «железо серверов», «здоровье» жестких дисков, сетевых маршрутизаторов и т.п.
Руками не трогать — разработка ведется отдельно
Жуткий по своему цинизму, но распространенный кейс — разработчики вносят изменения в код веб-проекта прямо на «боевых» серверах, часто ломая функционал проекта в течение дня, удаляя (конечно случайно) страницы сайта и данные…
Разработчикам так проще всего — зашел и поправил/сломал и сразу виден результат и разработчику и Клиенту :-)
Как боремся с этим кошмаром:
- Договариваемся со службой разработки о наличии отдельной конфигурации разработки где они все сначала делают
- Проверяем, что все изменения в веб-проект сначала тщательно тестируются разработчиками, их тестировщиками и вами (вашими подчиненными)
- Только при получении одобрения от вас «набор изменений» (можно назвать его «релиз») переносится на «боевые» сервера
- Изменения контента через админки делаются напрямую без привлечения разработчиков. Так мы сэкономим время
- Если есть возможность, договоритесь о возможности делать откат изменений назад в случае ошибки и времени выполнения отказа назад. Нередко об этом забывают и когда система разваливается на глазах рунета, начинают ее восстанавливать, долго и медленно — а так есть надежда аккуратно откатить изменения и вернуться на 5 минут в счастливое прошлое :-)
Если разработчики просят у вас ресурсов на создание подсистемы внутреннего автоматизированного тестирования кода (примерно из этой вселенной также технология «непрерывной интеграции» — ContinuosIntegration) и команде можно доверять — пойдите навстречу. Этим вы снизите риск разрушения проекта в местах A,B,C после внесения изменений в функционал D.
В последнее время крутится модная байка, что веб-проекты находятся перманентно в сыром состоянии (beta) и это не страшно, что баги недоделанного и быстро введенного в эксплуатацию функционала находят Клиенты и не нужно держать группы тестировщиков — на самом деле, если письма от Клиентов о потере заказов и проблемах разбирать не вам — … :-)
Датацентры и их количество
Ваши веб-проекты «живут» на серверах, которые, скорее всего находятся в одном, «очень надежном» датацентре. К сожалению, датацентры ломаются — в них бьет молния, дядя Вася на экскаваторе обрывает кабели питания, сходит с ума уборщица и обливает водой сервера и т.п. — в общем ваши веб-проекты могут стать недоступными на время от нескольких часов до нескольких дней.
Если вы готовы пережить такое — читайте следующую главу. Неплохо работает следующая схема, позволяющая с минимальным временем простоя (можно добиться простоя в несколько минут, если постараться) пережить крах датацентра:
- В другом датацентре держим «реплику» баз данных на более «слабом» и дешевом сервере. Т.е. все заказы, транзакции, обновления каталога — переносятся в фоновом режиме в другой датацентр. Для MySQL такая репликация настраивается довольно быстро, просто и работает надежно (есть риск потерять несколько последних транзакций, но говорят что научились не терять даже их).
- В другом датацентре держим «реплику» данных — файлов, изображений и т.п. Для этого, например, используют технологию DRBD. Настраивается просто и быстро.
- В случае суицида уборщицы в датацентре А мы переключаем доменные имена на датацентр B, а, т.к. в нем у нас уже есть все данные, причем последние, мы продолжаем обслуживать Клиентов. Если есть возможность, то можно держать в датацентре B аналогичные по мощности сервера — в этом случае Клиенты тем более ничего не заметят.
Элегантное и более простое решение данной задачи «быстрой миграции между ДЦ» предоставляет амазон. Датацентры там соединены высокоскоростными магистралями и «поднять» машины в другом датацентре, имея под рукой данные из свежих снэпшотов, можно за минуты!
Как потерять данные Клиентов навсегда?
Да, конечно все знают, что нужно делать резервное копирование данных веб-проекта. Скорее всего его делают… А вы пробовали их восстанавливать? :-) А знаете, что данные могут не восстановить по причине «испорченности» архивных копий?
Для борьбы с безответственностью и некачественной организацией резервного копирования полезно согласовать с it-подразделением план проведения «учений по восстановлению» — при котором, например, раз в месяц, проводится тестовое восстановление на отдельной машине ваших веб-проектов.
Еще лучше, включить в созданную нами систему мониторинга несколько тестов, которые «выбьют» если по какой либо причине резервные копии не будут сделаны либо не смогут быть прочитанными при восстановлении.
А сломать процесс резервного копирования, при высоком уровне раздолбайства профильных специалистов — легко и я лично на практике сталкивался с ситуацией, когда все думают что резервные копии делаются, а на деле — диск переполнился давно :-)
Любопытно поинтересоваться у it-службы: «А сколько времени будет восстанавливаться веб-проект из резервной копии в случае потери данных или аварии в датацентре?» Технически, при организации репликации (см. выше), можно обеспечить это за минуты (либо десятки минут). Однако можно услышать и такой ответ: «Данные восстановим суточной давности, а база данных будет заливаться из резервной копии часа 3» :-). Будьте бдительны.
Итог
При желании и определенной напористости можно довольно быстро настроить бизнес-процесс мониторинга и восстановления вверенных вам веб-проектов. Особенно если вы разместитесь в облаке. Техническая возможность… перманентного творческого наслаждения ProductOwner — имеется :-)
