J3qx

information archive

План обеспечения непрерывности ИТ сервисов. CIO

Posted by j3qx на Ноябрь 26, 2016

План обеспечения непрерывности ИТ сервисов

Основные положения

Целю данного документа является подготовка ИТ департамента компании Example к форс-мажорным случаям (выходы из строя оборудования и ПО, катастрофам, стихийным бедствиям, саботажу и т.д.), приводящим к длительному перебою в предоставлении ИТ услуг. Результатом выполнения комплекса мер, описанных в данном документе, должно быть скорейшее возобновление предоставления ИТ услуг в максимально большом объеме и с минимальными издержками.

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

Ознакомление ответственных за восстановление сотрудников с данным планом подразумевает понимание ими ответственности за выполнение подготовительных работ и незамедлительное реагирование по факту возникновения экстренного случая.

Область применения данного документа ограничена экстренными случаями. Рабочие инциденты обрабатываются согласно регламентам служб поддержки каждого из проектов.

Команды экстренного реагирования

В команде экстренного реагирования существует несколько ролей, связанных с различными областями ответственности:

  • ИТ руководство
  • Поддержка сайта
  • Поддержка 1С
  • Поддержка WMS
  • Поддержка инфраструктуры

За каждой ролью в обязательном порядке закреплены минимум два человека. Старший сотрудник, закрепленный за каждой из ролей, несет ответственность за обновление контактных данных всех сотрудников, связанных с данной ролью по факту их изменения.

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

Приоритеты информационных систем

Все составные части ИТ инфраструктуры компании разделяются на две категории: системы критичные для бизнеса и вспомогательные системы.

К системам, критичным для бизнеса, относятся:

  • Сайт Example.ru
    • load balancer
    • nginx
    • Tornado
    • MySQL
    • Reddis
    • Sphinx
    • Memcache
    • RabbitMQ
    • веб-сервис компании «Телеконтакт»
    • веб-сервисы курьерский компаний (SPSR, PickPoint, DPD, Почта России
  • BOB Delivery tool

    • 1C приложение
    • MS SQL
    • eProduction tool
  • WMS
    • WMS приложение
    • Example Bus
    • PostgreSQL
    • CUPS
  • Top Logistic
    • Top Logistic приложение
    • MS SQL
  • Avaya
  • FTP сервер файлового обмена
  • интернет-каналы
    • дата-центра
    • офиса
    • склада
  • офисные входящие телефонные линии
  • сервера и сетевое оборудование, относящиеся к вышеперечисленным системам
  • складское оборудование беспроводного доступа к сети WiFi

К вспомогательным системам относятся:

  • Сайт Example.ru
    • Prudsys
    • Sentry
    • Double click
    • Adobe Ad Lens
    • веб-сервис UMS
    • веб-сервис sms-gate
    • тестовые стенды сайта
    • виртуальные площадки программистов
  • Клиент-банк
  • DWH
    • Oracle DB
    • Pentaho
    • SAP Business Object
    • Unica
  • OTRS
  • Jira
  • Confluence
  • 1C-Bitrix Интранет
  • Nagios
  • Simantec Backup Exec
  • MS Active Directory
  • SMB сервер файлового хранения
  • офисные входящие телефонные линии
  • сервера и сетевое оборудование, относящиеся к вышеперечисленным системам
  • офисное оборудование беспроводного доступа к сети WiFi

Политика резервного копирования

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

  • файлы, наличие которых является обязательным для работоспособности критических систем;
  • невосстановимые файлы;
  • файлы, восстановление которых трудоемко или дорого;
  • журналы доступа и изменения данных.

Носители резервных копий должны быть расположены в защищенном от несанкционированного доступа, географически отличном от изначальной системы месте с допустимой разумной защитой от стихийных бедствий.

Базовым режимом хранения резервных копий является:

  • хранение инкрементальных копий за каждый час на протяжение 24 часов;
  • хранение полной копии суточной давности;
  • хранение инкрементальных копий за каждый день на протяжение 7 дней;
  • хранение полной копии недельной давности;
  • хранение полной копии за каждый прошедший месяц календарного года;
  • хранение итоговой копии за каждый прошедший календарный год.

В зависимости от использования каждой системы в бизнес-процессах компании, архитектор или руководитель группы разработки и сопровождения принимают обоснованное решения об изменении режима хранения копий, тем самым принимая ответственность за сохранение возможности восстановления копий в вышеперечисленных диапазонах.

Используемые для хранения копий медиа-носители (серверные жесткие диски) должны заменяться на новые реже раза в полтора года. Годовые архивы должны дублироваться на ленточные или CD носители и храниться в сейфе вне серверных помещений. Ответственность за выполнение данных процедур несут сотрудники поддержки инфраструктуры.

Проверочные списки

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

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

Также данные списки используются для обучения новых сотрудников и проведения тестовых проверок текущими сотрудниками команды экстренного реагирования.

Информирование об инциденте (0 часов)

Данный план применяется только в случае наступления экстренного случая. В случае возникновения операционных проблем, сотрудники должны следовать установленному порядку информирования команд поддержки о возникновении инцидента.

Основанием для объявления экстренного случая являются:

  • неработоспособность критичной для бизнеса системы на протяжение двух и более часов;
  • неработоспособность пяти и более систем на протяжении четырех и более часов;
  • любые проблемы в программном, аппаратном обеспечение или сетевой инфраструктуре, которые, очевидно, приведут к возникновению вышеперечисленных случаев.

При возникновении экстренного случая, сотрудники, обнаружившие его, должны связаться с руководителем ИТ и предоставить следующую информацию:

  • географическое местоположение и информационная система, связанная с экстренным случаем;
  • свои ФИО и контактные данные, а также информацию о доступном руководителе своего подразделения / рабочего процесса;
  • известные причины, уже нанесенный или возможный ущерб;
  • период действия причины, если известно.

Начало действия данного плана (2/4 часа)

Данный план вступает в действие по факту объявления экстренного случая руководителем ИТ. Он же определяет состав группы, необходимой для решения возникшего случая и информирует соответствующих сотрудников команды экстренного реагирования.

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

Руководитель ИТ назначает ответственного сотрудника, который в дальнейшем координирует работу всей группы и отвечает за возобновление предоставления ИТ услуг.

Шаг 1: Выполнение проверочного списка (4/6 часа)

На основе полученной информации и в соответствие с имеющимися по системе(ам) проверочными списками сотрудники команды экстренного реагирования выполняют актуальные для данного случая пункты:

  • экстренное резервное копирование;
  • перевод систем в режим максимального мониторинга и сбор дополнительной информации;
  • проверку работоспособности систем и поиск причин возникновения экстренного случая;
  • получение информации об экстренном случае от поставщика услуг;
  • проверку наличия работоспособной резервной копии системы;
  • проверку готовности дублирующих систем;
  • возможность исключения вышедших из строя систем из активных бизнес-процессов компании.

Шаг 2: Возобновление работоспособности систем (8/10 часов)

На основании собранной на первом шаге информации, ответственный сотрудник принимает решение о возможности использовать один из методов возобновления работоспособности бизнес-процесса:

  • устранение причин возникновения экстренного случая и возобновление работоспособности систем;
  • восстановление резервной копии / предыдущей работоспособной версии системы;
  • ввод в действие дублирующих систем на замену вышедшим из строя;
  • выключение из бизнес-процесса неработоспособных систем с заменой их альтернативными системами / ручным трудом.

Результат выполнения второго шага в обязательном порядке проверяется на протяжение 4-ех часов минимум (более, если это требуется процессом). Бизнес-процесс считается возобновлённым только после подтверждения этого факта сотрудником, обнаружившим экстренный случай и/или его руководителем.

В случае невозможности возобновления работоспособности систем за 4 часа, ответственный сотрудник связывается с руководителем ИТ. На основание собранных данных руководитель ИТ связывается с руководителями структурных подразделений / компании для принятия решений о возможном выключении в компании всего бизнес-процесса на период его восстановления.

Шаг 3: Полное восстановление систем

Полное восстановление систем подразумевает возврат к основной конфигурации системы в соответствие с архитектурой предприятия. Данный шаг не регламентирован и сильно зависит от конкретной системы.

Основные действия, приводящие к восстановлению систем:

  • закупка замены вышедшего из строя оборудования / восстановление аппаратного резерва;
  • заключение контрактов с альтернативными поставщиками услуг;
  • исправление ошибок в программном обеспечение, замена его на более стабильное или дублирование его резервным;
  • включение системы в мониторинг, расширение наблюдаемых параметров;
  • проведение обучения сотрудников, включение дополнительных обязанностей/ответственности в их должностные инструкции;
  • включение экстренного случая в проверочный лист с описанием типового решения.

Пересмотр плана и поддержка актуальности

Данный план пересматривается на постоянной основе не реже чем раз в полгода. В ходе проверки пересматриваются: списки систем и их приоритет, списки сотрудников команды экстренного реагирования и их контактные данные. Не реже чем раз в год проводятся проверки связанных планов восстановления работоспособности отдельных системы, наличие резервного оборудования, наличие и порядок хранения резервных копий.

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

Электронная версия данного плана и планов по отдельным системам хранятся в публичном разделе корпоративного Интранет-портала.

Список контактов для уведомления о наступлении экстренного случая

Имя Фамилия

Область ответственности

Почта

Сотовый телефон

История проверок и изменений плана

Дата

ФИО

Краткое описание результатов проверки

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: