Отвлекитесь на минутку от чтения и ответьте для себя на вопрос: как в конечном итоге для Вас критичен простой Вашего сервиса длительностью в 1 60 секунд? Ответили? Думаю, если не все, то большая часть из читателей поразмыслили: «Переживём».
А сейчас ответьте, как критичен простой в 5 мин.? А в 30, час, дни? На каком-то из шагов в голове раздастся: «Нет, ну это уже многовато». Только что Вы заложили один из серьёзных параметров, нужных для составления замысла обеспечения непрерывности работы ИТ сервиса.
О том, что это такое, и какой к нему лучше подходит соус, просматривайте под катом.
Смотрите кроме этого: Из Гугл Play возможно будет вернуть приложения с определённого устройства
В ОС Android функции автоматического резервного копирования и восстановления трудятся не так, как того хотелось бы. Некоторым пользователям достаточно стандартных сервисов по восстановлению и копированию компании Гугл, а кое-какие предпочитают сторонние приложения, как, к примеру, Titanium Backup. Сейчас поступила информация, что Гугл планирует улучшить сотрудничества между функциями восстановления и копирования.В соответствии с новой информации, Гугл трудится над совокупностью восстановления, которая будет трудиться через Гугл Play Store, а не только через настройки Android.
Всё когда-то выходит из строя. Предвещая одолжений по аренде выделенных серверов, мы иногда замечаем, как различные пользователи решают неприятности по восстановлению и обеспечению работоспособности собственных одолжений. И мы сделали печальный вывод: не обращая внимания на то, сколько всего написано и сообщено на тему резервирования данных и оборудования, у некоторых ресурсов до сих пор нет какой-либо проработанной стратегии восстановления.
В то время, когда что-то случается, они просто начинают агонизировать, хаотически дёргать сотрудников, а иногда и обвинять всех в чём-то.«Планирование непрерывности бизнеса (кроме этого время от времени именуется планированием отказоустойчивости и непрерывности бизнеса) определяет, как организация подвергается внутренним и внешним угрозам, и задаёт программные инструменты и необходимые аппаратные, разрешающие обеспечить восстановление и эффективное противодействие обычного функционирования организации с сохранением системной целостности и конкурентного преимущества» (Эллиот и др., 1999).Данный термин изначально введён для более «тяжёлых» случаев — нарушений в работе контор либо дата-центров, вызванных пожарами, стихийными бедствиями, преступными прочими третьих случаями и действиями лиц, каковые в большинстве случаев происходят значительно менее, чем, к примеру, выход из строя твёрдого диска. Английский университет стандартов кроме того выпустил особый стандарт по управлению непрерывностью бизнес-процессов — BS 25999.
Но мы не будем так углубляться, а просто постараемся оказать помощь Вам осознать для себя, как и как основательно Вам стоит подготавливаться к вероятным перебоям.Что Вы готовы утратить?Любой бизнес сопряжён с определёнными рисками. И чтобы бизнес был успешен, риски не должны быть чем-то, что живёт само по себе, ими необходимо руководить.
Для ИТ сервисов и проектов, размещаемых в сети, имеется некоторый комплект характерных рисков, приводящих ко временной недоступности проекта, любой из которых возможно охарактеризовать математически такими параметрами, как возможность происхождения, длительность действия, цена полного либо частичного сглаживания/устранения действия.При происхождении нештатной обстановке имеется три главных параметра, каковые смогут «теряться»: эти, деньги и время. Сопутствующие неприятности в виде утраты репутации, потерянной пользы и т.п. в итоге возможно свести к этим трём.Между параметрами существует тонкая сообщение.
К примеру, чем меньше Вы готовы утратить времени и данных, тем больше денег Вам необходимо положить в информации и резервирование мощностей. При понижении затрат с сохранением времени восстановления может увеличиться утрата данных. И без того потом.Ещё перед тем, как посмотреть под кат, Вы, надеюсь, уже выяснили, какое большое время простоя возможно для Вашего проекта. В терминологии планирования отказоустойчивости данный параметр именуется целевым временем восстановления (recovery time objective, RTO).
Это время, за которое должно быть восстановлено обычное функционирование сервиса либо бизнес-процесса для предотвращения тяжёлых последствий. Конечно, что для Вас есть тяжёлыми последствиями, Вы кроме этого должны выяснить для себя сами.Второй ответственный параметр, что Вы должны оценить при планировании, — целевая точка восстановления (recovery point objective, RPO). Это ещё один временной промежуток.
Он характеризует большое приемлемое время, за которое смогут быть утеряны эти ИТ сервиса. Параметр данный обрисовать пара сложнее. Запрещено просто заявить, что это допустимый количество утраты данных, не смотря на то, что в нулевом приближении его как раз так и разглядывают.
Грубо говоря, это предельное время В первую очередь создания последней дешёвой резервной копии до точки аварии.Имеется ещё два параметра — актуальные точка и время восстановления, но их возможно определить или в ходе симуляции, или при самой аварии.В больших компаниях целевые показатели определяют особые аналитики, занимающиеся вопросами отказоустойчивости, каковые передают после этого задачу группе экспертов по техобеспечению заданных показателей. Они, со своей стороны, определяют, где, что и в каких количествах необходимо хранить, резервировать и держать на тёмный сутки.Но в случае если Ваш проект складывается из Вас и Вашего программиста либо сисадмина, это совсем не предлог всецело закинуть таковой анализ и заявить, что это не про Вас.
На отечественной практике был несколько случай, в то время, когда из-за полнейшего отсутствия продуманной стратегии контроля за работоспособностью и восстановления у людей появлялись неприятности от проседания в индексе поисковых машин до приблизительно полудневной недоступности некоего денежного инструмента либо сервиса, т.к. все сведенья хранились на одном сервере, и никакая текущая своевременная репликация не производилась.Кто виноват?Прежде всего, начальник проекта и его важные эксперты. Провайдеры делают всё, что в их силах, для обеспечения большого аптайма, но фактически в любом соглашении-оферте будет написано (быть может, третьим шрифтом), что провайдер не несёт никакой ответственности за потерю и любые перебои данных по любым обстоятельствам.
Кроме того в случае если пьяный инженер случайно отформатирует не тот сервер, вполне возможно ни на что важнее сожалений и искренних извинений Вам рассчитывать не будет необходимо. Помимо этого, напомню тезис: всё когда-нибудь выходит из строя. Кроме того то, что позиционируется как сверхбесперебойная услуга (достаточно отыскать в памяти масштабный даунтайм облака Amazon).Сохранность Ваших данных и работоспособности одолжений обязана тревожить в первую очередь как раз Вас.
Как раз Вы должны дать ответ на следующий вопрос:Что делать?Обучаться на чужих неточностях, как это вероятно. Современное информационное пространство разрешает проанализировать опыт великого множества отказов и оценить потенциальные не сильный места собственного проекта.Первое, что необходимо сделать на пути к составлению замысла обеспечения непрерывности работы, — избавиться от иллюзий. Был на отечественной практике случай, в то время, когда пользователь необходимость делать бэкапы.
Не получило корректно автоматическое резервное копирование в панели управления — ну и не нужно. Он честно думал, что RAID1 его спасёт. Каково же было его удивление, в то время, когда первый диск в массиве значительно деградировал, а на втором была масса неточностей в файловой таблице.
Попытка оперативно заменить первый диск и пересобрать массив ни к чему хорошему не привела, как возможно додуматься. Отечественным администраторам было нужно возвращать трудящийся на грани полного отказа диск и мучительно продолжительно извлекать из него эти байт за байтом. Довод, из-за чего пользователь не делал бэкапы, нас поразил: «У меня за 6 лет работы ни при каких обстоятельствах для того чтобы не было».
По всей видимости, чем раньше в жизни администратора случается большая утрата данных, тем лучше для его будущих проектов.Второе — выясните потенциальные угрозы, их продолжительность и вероятность действия. какое количество времени пригодится на переключение на сервис фильтрации DDoS? какое количество времени займёт замена диска либо сервера полностью в Вашем дата-центре?
какое количество времени пригодится на развёртывание проекта в другом ЦОД, в случае если в Вашем произойдёт пожар, наводнение, либо легко провайдер неожиданно прекратит собственное существование? Где его развёртывать, за какое время будет предоставлено новое оборудование и т.п. В случае если полученные цифры не укладываются в ожидаемое Вами RTO, заблаговременно поищите вторых провайдеров, инфраструктура которых окажет помощь Вам восстановиться.
Кроме этого определитесь, сколько данных Вы готовы утратить, и подберите подходящую схему резервирования.Третье — посчитайте. Как я уже писал, чем меньше утраты времени и данных, тем дороже Вам это обойдётся. Оцените разовые и регулярные затраты для обеспечения нужных Вам значений показателей непрерывности. Вы готовы платить взятую сумму?
В случае если нет, значит, Вам не так ответственны эти, как Вы поразмыслили раньше. Совершите повторную оценку, но уже с учётом Вашего бюджета на восстановление.Четвёртое — внедряйте. оценки и Простого подсчёта не достаточно. Необходимо применить нужные меры на практике.
Закажите нужное услуги и резервное оборудование, подпишите нужные соглашения, включите мониторинг. Распишите для себя в текстовом документе, к какому сервису в каких случаях обращаться, какая процедура действий в том либо другом случае. Возможно кроме того разок совершить симуляцию того либо иного отказа. За наличие чёткой и последовательной инструкции Вы ещё сообщите себе благодарю, в то время, когда что-то произойдёт.
Наличие прописанного замысла восстановления разрешит Вам значительно сэкономить пучок и время нервов. Обстановка из разряда непредвиденных перейдёт легко в разряд чрезвычайных. Вы уже не станете блуждать во мраке, как слепой котёнок.Сокровище чего-либо в нашей жизни определяется тем, большое количество ли мы готовы дать, дабы это сохранить. Если Вы вправду цените результаты собственного труда, не забудьте позаботиться об их сохранности.
Кто, если не Вы?