Доступность веб-проектов — спокойной ночи, ProductOwner

    Вы — ProductOwner и отвечаете за группу веб-проектов. Когда сайты висят, недоступны или Клиентам выводится отладочная информация типа «Exception in object COrderController constructor… » — вам начинают звонить на мобильный, писать в твиттер и т.п.:
    • топ-менеджер (или генеральный)
    • коллеги, некоторые злорадствуя
    • наши уважаемые Клиенты

    Еще веселее, когда вас дергают… вечером за ужином, в иное время во время исполнения супружеских обязанностей, в отпуске :-)
    Разберем популярные кейсы, ключевые принципы обеспечения доступности веб-проектов и попытаемся выстроить чеклист «Безмятежного отпуска».


    Сокращаем время реагирования


    По-хорошему, нужно узнать о проблемах с веб-проектом РАНЬШЕ, чем на нее нарвался Пользователь сайта — и постараться исправить ситуацию. Хуже, когда о проблеме с вашим веб-проектом узнали десятки (тысяч) Пользователей, ваш руководитель, и успели даже обсудить «висение» в твиттере, сделать скриншот ошибки.
    Часто происходит следующим образом:
    • сайты висят, несколько минут или больше
    • Клиенты пишут/звонят вам и коллегам, в т.ч. в твиттер компании
    • вы пишете сисадмину или в службу системного администрирования
    • сисадмин говорит, что перезагрузит апач, после чего веб-проекты снова доступны

    Спасибо что сказали, сейчас апач перегружу... — т.е. пока не толкнешь в з..., никто ничего не сделает.
    В результате простой веб-проекта составляет до десятков минут. Придется объясняться перед Пользователями, почему ваш крутой, высокотехнологичный веб-проект с ценными данными Клиентов — висел.
    Есть отличный недорогой бизнес-процесс, позволяющий реагировать ПРОАКТИВНО. Поступаем так:
    1. Договариваемся со службой системного администрирования настроить автоматизированный мониторинг ваших веб-проектов. Для этого существует немало бесплатного эффективного софта. Мы пользуемся nagios, многие используют zabbix и др. Настроить подобный софт — несколько часов. Что тестировать? Самый простой кейс: время загрузки страницы вашего веб-проекта и наличие на ней уникальной сигнатуры, например, номера телефона в футере.
    2. «Кто-то» должен среагировать в случае уведомления о проблеме от системы мониторинга. Если «кто-то» обедает или курит на полчаса, веб-проекты будут висеть эти полчаса. Очень помогает настройка отправки сисадминам смс на мобильники. На mail.ru, правда с ограничениями, можно отправлять смс-ки c вашего почтового ящика беспатно, но не чаще раз в полчаса. Если купить подписку на сервис рассылки смс, то они будут доставляться быстрее и без ограничений. Настроить процесс отправки системой мониторинга смс на мобильные сисадминам — минут 30. Если не дают добро на сервис отправки смс, можно, как минимум, заставить систему мониторинга делать почтовую рассылку всем сисадминам, вам и вашим коллегам — можно надеяться, что кто-нить из сисадминов будет на рабочем месте и отреагирует.
    3. «Кто-то» должен среагировать на проблему с вашим веб-проектом… на выходных, ночью, в праздники (например, в первых числах января). Нередко сталкивался со случаями, когда о висении веб-проектов на выходных или новогодние праздники узнавали… не сразу, а через несколько часов или дней. Просто никого из сисадминов не было на работе :-) В этом случае можно поступить так — договориться со службой техподдержки об организации дежурств во вне рабочее время — в это случае будет «кто-то», кто сможет и, главное, должен среагировать.

    В данной точке мы можем надеяться, что о проблеме с вашим веб-проектом раньше или одновременно с Клиентами ТОЧНО УЗНАЕТ кто-то из службы системного администрирования и отреагирует В ЛЮБОЕ ВРЕМЯ.
    В серьезных организациях для решения задачи оперативного реагирования можно попробовать согласовать с IT-службой «договор» об SLA, куда включить вышеуказанные задачи.
    Рекомендую размещать машину мониторинга в другом датацентре — проследите. Если, как это часто бывает с отечественным хостингом (да и, как помним, в амазоне недавно тоже жестко «упал» один датацентр, где были наши машины), датацентр обесточится на несколько часов, то также отключится и наша машина мониторинга и никто внутри компании ничего не узнает, если инцидент произойдет на выходных :-)

    Проактивный мониторинг — снаружи


    Наверняка ваш веб-проект предоставляет Клиентам различные сервисы: отправка ключей, почтовых уведомлений по заказам, загрузку файлов и т.п. — эти сервисы тоже нужно включить в систему мониторинга. «Морда» веб-сайта может открываться, а вот загрузка файлов Клиентами в персональном разделе — не работать.
    Поэтому требуем наличия постоянного мониторинга N сервисов нашего веб-проекта и надеемся, что получив уведомление «Сервис обработки заказов — не работает» мы узнали о проблеме сразу и ее решением уже начали заниматься ответственные.

    Проактивный мониторинг — изнутри


    Часто веб-проекты ломаются… постепенно. Уменьшилось место на диске сервера, перестали работать внутренние службы, отвечающие за резервирование и работу под нагрузкой — никто на это не отреагировал, а можно было…
    Поэтому важно проследить, чтобы автоматический мониторинг проверял не только доступность ваших сайтов, но и работоспособность серверов, служб, баз данных и прочая и прочая. Полезно убедиться что служба системного администрирования делает это или начнет этим заниматься системно.
    Опять-таки, для решения данной задачи используется бесплатный софт, который можно настроить достаточно быстро.
    В результате мы надеемся, что некоторые отказы, влияющие косвенно на работоспособность веб-проектов, постоянно мониторятся, исправляются и не накапливаются до критической массы: проверяется «железо серверов», «здоровье» жестких дисков, сетевых маршрутизаторов и т.п.

    Руками не трогать — разработка ведется отдельно


    Жуткий по своему цинизму, но распространенный кейс — разработчики вносят изменения в код веб-проекта прямо на «боевых» серверах, часто ломая функционал проекта в течение дня, удаляя (конечно случайно) страницы сайта и данные…
    Разработчикам так проще всего — зашел и поправил/сломал и сразу виден результат и разработчику и Клиенту :-)
    Как боремся с этим кошмаром:
    • Договариваемся со службой разработки о наличии отдельной конфигурации разработки где они все сначала делают
    • Проверяем, что все изменения в веб-проект сначала тщательно тестируются разработчиками, их тестировщиками и вами (вашими подчиненными)
    • Только при получении одобрения от вас «набор изменений» (можно назвать его «релиз») переносится на «боевые» сервера
    • Изменения контента через админки делаются напрямую без привлечения разработчиков. Так мы сэкономим время
    • Если есть возможность, договоритесь о возможности делать откат изменений назад в случае ошибки и времени выполнения отказа назад. Нередко об этом забывают и когда система разваливается на глазах рунета, начинают ее восстанавливать, долго и медленно — а так есть надежда аккуратно откатить изменения и вернуться на 5 минут в счастливое прошлое :-)

    Если разработчики просят у вас ресурсов на создание подсистемы внутреннего автоматизированного тестирования кода (примерно из этой вселенной также технология «непрерывной интеграции» — ContinuosIntegration) и команде можно доверять — пойдите навстречу. Этим вы снизите риск разрушения проекта в местах A,B,C после внесения изменений в функционал D.
    В последнее время крутится модная байка, что веб-проекты находятся перманентно в сыром состоянии (beta) и это не страшно, что баги недоделанного и быстро введенного в эксплуатацию функционала находят Клиенты и не нужно держать группы тестировщиков — на самом деле, если письма от Клиентов о потере заказов и проблемах разбирать не вам — … :-)

    Датацентры и их количество


    Ваши веб-проекты «живут» на серверах, которые, скорее всего находятся в одном, «очень надежном» датацентре. К сожалению, датацентры ломаются — в них бьет молния, дядя Вася на экскаваторе обрывает кабели питания, сходит с ума уборщица и обливает водой сервера и т.п. — в общем ваши веб-проекты могут стать недоступными на время от нескольких часов до нескольких дней.
    Если вы готовы пережить такое — читайте следующую главу. Неплохо работает следующая схема, позволяющая с минимальным временем простоя (можно добиться простоя в несколько минут, если постараться) пережить крах датацентра:
    • В другом датацентре держим «реплику» баз данных на более «слабом» и дешевом сервере. Т.е. все заказы, транзакции, обновления каталога — переносятся в фоновом режиме в другой датацентр. Для MySQL такая репликация настраивается довольно быстро, просто и работает надежно (есть риск потерять несколько последних транзакций, но говорят что научились не терять даже их).
    • В другом датацентре держим «реплику» данных — файлов, изображений и т.п. Для этого, например, используют технологию DRBD. Настраивается просто и быстро.
    • В случае суицида уборщицы в датацентре А мы переключаем доменные имена на датацентр B, а, т.к. в нем у нас уже есть все данные, причем последние, мы продолжаем обслуживать Клиентов. Если есть возможность, то можно держать в датацентре B аналогичные по мощности сервера — в этом случае Клиенты тем более ничего не заметят.

    Элегантное и более простое решение данной задачи «быстрой миграции между ДЦ» предоставляет амазон. Датацентры там соединены высокоскоростными магистралями и «поднять» машины в другом датацентре, имея под рукой данные из свежих снэпшотов, можно за минуты!

    Как потерять данные Клиентов навсегда?


    Да, конечно все знают, что нужно делать резервное копирование данных веб-проекта. Скорее всего его делают… А вы пробовали их восстанавливать? :-) А знаете, что данные могут не восстановить по причине «испорченности» архивных копий?
    Для борьбы с безответственностью и некачественной организацией резервного копирования полезно согласовать с it-подразделением план проведения «учений по восстановлению» — при котором, например, раз в месяц, проводится тестовое восстановление на отдельной машине ваших веб-проектов.
    Еще лучше, включить в созданную нами систему мониторинга несколько тестов, которые «выбьют» если по какой либо причине резервные копии не будут сделаны либо не смогут быть прочитанными при восстановлении.
    А сломать процесс резервного копирования, при высоком уровне раздолбайства профильных специалистов — легко и я лично на практике сталкивался с ситуацией, когда все думают что резервные копии делаются, а на деле — диск переполнился давно :-)
    Любопытно поинтересоваться у it-службы: «А сколько времени будет восстанавливаться веб-проект из резервной копии в случае потери данных или аварии в датацентре?» Технически, при организации репликации (см. выше), можно обеспечить это за минуты (либо десятки минут). Однако можно услышать и такой ответ: «Данные восстановим суточной давности, а база данных будет заливаться из резервной копии часа 3» :-). Будьте бдительны.

    Итог


    При желании и определенной напористости можно довольно быстро настроить бизнес-процесс мониторинга и восстановления вверенных вам веб-проектов. Особенно если вы разместитесь в облаке. Техническая возможность… перманентного творческого наслаждения ProductOwner — имеется :-)
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 34

      +1
      Хорошая статья.

      Вроде бы — азы, давно известные истины… Но не много знаю компаний, где все это систематизировано и учтено.

      Может, даже ближе к «Информационной безопасности», а не к PM.
        +2
        Поделились мыслями — спасибо, но мало. Кому пишите?

        Если для начинающесь продукт оунеров — то они остановятся на SMS. Для такой аудитории надо расписать конкретику — где брать рекомендованных админов для постоянного пригляда, каким способом отзеркалировать сервера в другой ДЦ или как быстро их поднять из бекапа.

        Если для опытных овнеров — то они это и так в голове держат, а хочется посмотреть рабочий документ/докладную записку из вашей компании типа «План реализации мероприятий по обеспечению безотказному функционированию вербсервисов (редакция 3.Х, исправленная)», где раскрыты критерии отказоустойчивости, административные и технические мероприятия, расписания учений регулярных проверок. Как-то так.

          +2
          Я написал скорее в духе как продуктовнеру воспитать или подобрать техдира и проконтролировать его работу :-)
          –4
          Спасибо. Интересно. Взял на заметку. А зачем настраивать софт, достаточно установить на сайт яндекс метрику.
            0
            Вот для вас и написана эта статья! :)
            +4
            Дочитал до SMS, а потом стало скучно… Автор! Больше экшена и конкретики! И какого фига вы пишете такую ерунду, как «На mail.ru, правда с ограничениями, можно отправлять смс-ки c вашего почтового ящика беспатно, но не чаще раз в полчаса.»???? Как ваш замечательный nagios отправит SMS'ку, если тупо пропадет доступ в интернет? Раньше было сложнее — если хотелось бюджетное решение, то нужно было подключать мобильники и т.п. А сейчас же USB-модемы стоят копейки — хоть оботправляйся этих SMS'ок…
              –2
              Ну это же проще смс-ки отправлять нагиосом через веб-шлюз — одна строка в конфиге. Согласен, напрямую USB-модемом — надежнее, но нужно уметь мобильники к юниксу подключать :-)
                +1
                [удивленно] Мы за простоту или за надежность говорим?
                Насчет «нужно уметь» — давайте разделять мух и котлеты: уметь нужно администратору — ему за это деньги платят, — а если не умеет (что тоже нормально), то пусть учится. А именно owner'у нужно знать, что это возможно и требовать этого с администраторов (вроде как именно об этом пост?), чтобы не было как в комменте чуть выше — админу сказали «Обеспечь уведомление по SMS!», а админ поставил Яндекс.Метрику на сайт и думает, что он теперь весь из себя такой замечательный и «обеспечил» — это же несерьезно…
                  +1
                  Я вот думаю как к нашим серверам в амазоне прицепить USB-модем. Похоже пока никак, придется через смс-шлюз. :-)
                    0
                    Я думаю, что сервера на Амазоне проще и надежнее проверять снаружи с других серверов, которые НЕ на Амазоне. :-) А вот в те другие — уже вставлять USB-модем и пусть шпарит…
              +1
              >успели даже обсудить «висение» в твиттере…
              >Клиенты пишут/звонят вам и коллегам, в т.ч. в твиттер компании

              Как же шагнул прогресс за последние годы…
                0
                > «боевые» сервера
                удобнее называть это production-серверами
                  0
                  Именно поэтому Господь изобрёл хостеров. Здравствуйте статья из конца XX-го века.
                    +1
                    У большинства хостеров — один датацентр :-) А это — уже не XXI век, посмотрите на архитектуру, к примеру, амазона.
                      0
                      Чо, круто амазону. Не вижу ничего такого в одном или нескольких датацентрах. То что приписывают Амазону — безотказность — у них тоже не очень и не всегда. При том что «один датацентр» в общем случае достаточно редко падает, баланс между вот этим всем что написано, стоимостью и потерями от технических простоев в исключительных случаях — всё это явно не в пользу Амазона. Опять же в общем случае.
                    0
                    Автор, все прекрасно знают, что существует огромное количество программ автоматизированного мониторинга. Нужно было привести конкретные примеры, ваш пост было читать, прямо скажем, неинтересно.
                      +1
                      Так я пишу для продктовнеров — как выжать максимум с техдира и службы системного администрирования :-). А по опыту многие не знают о программах мониторинга и звонят админу — «перезапусти плз. апач».
                      +1
                      Много лирики. Мало конкретики. Но общий принцип, я думаю многим нелохо почитать и такой
                        +1
                        Статья для управленцев — распечатают и будут использовать как чеклист. Конкретику думаю предоставит служба эксплуатации.
                        0
                        В целом, да, интересно. Но слишком много теории. Хочется примеров
                        Может будет продолжение? :)
                          0
                          Планирую рассказать как мы делаем бэкапы между датацентрами в амазоне.
                          +1
                          Я бы добавил:
                          • автоматический мониторинг должен быть, по-хорошему, распределенным — «другая» площадка на которой он запущен так же ненадежна, как площадка основного проекта. А если мониторинг «лежит», то он не нужен;
                          • днс должны быть правильно настроены и расположены — к сожалению, это не для всех сисадминов очевидно. Нельзя располагать все днс внутри одной сети (тем более, внутри локальной сети компании, которая по определению менее надежна, чем средненький хостинг). Чтобы изменить адрес сервера надо иметь свой днс и менять именно записи, а не адреса ДНС в настройках домена у регистратора. В первом случае изменения почти мгновенные, во втором — до 6 часов.

                            0
                            Надо же, на Хабрахабре наконец <ul>……</ul> по-человечески заработал в комментариях.

                            Радость, радость.
                              0
                              Можно кстати и полезно мониторить саму машину мониторинга. В нагиосе есть такая возможность.
                                0
                                А чем нагиос лучше забикса?
                                  0
                                  Вроде первый проще и легче.
                              +1
                              Мне всегда было интересно: что побуждает некоторых писать «Клиент» и «Пользователь» с большой буквы? Это же вроде бы норма только для юридических документов («… именуемый в дальнейшем "Клиент"...»); в обычных текстах это смотрится довольно дико и сильно режет глаз. Или это требование корпоративного стандарта?
                                +1
                                Это признак уважения к ним :-)
                                  0
                                  Больше похоже на попытку подлизаться:) Да и не по правилам языка это.
                                    0
                                    А начать следовало бы с уважения к коллегам: так и вижу картину как иванушка-дурачёк«начинающий productowner» прочтёт этот опус и начнёт что-то такое «выжимать максимум» и «воспитывать» тех.дира и всех подряд «толкать в зад». Только сотрудничество и только уважение.
                                    Повышение доступности стоит денег. Зачастую немалых.Чем ближе мы приближаемся к 1 тем дороже каждый шаг. Если у компании есть ресурсы пойти по этому пути и есть потребность — так надо разработать план, выделить ресурсы и реализовывать его. Ну а если нет — то так и не надо заниматься ИБД.
                                      0
                                      Согласен полностью.
                                  0
                                  Я так понимаю, эта статья «Основы системного администрирования для Product Owner'ов»?
                                    0
                                    Скорее основы управления службой поддержки и ее рисками для руководителя проекта :-)
                                    0
                                    Очень понравилось, спасибо!

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое