В прошлом году Америке не слишком повезло – в конце октября на нее обрушился тропический ураган Сэнди – восемнадцатый атлантический циклон с женским именем и неженским характером. Не соврем, если скажем, что запомнился он жителям всей планеты, хотя и не был самым мощным в истории человечества – тому виной вышедший ранее на большие экраны фильм-катастрофа «2012», в котором предсказания индейцев Майя о конце света, который якобы должен наступить именно в 2012 году, трактовались весьма однозначно: мир погибнет от сильнейших землетрясений и цунами. И вот, события фильма стали разворачиваться в режиме реального времени, и наблюдать за этим страшно было даже по телевизору – что уж говорить о жертвах и свидетелях разбушевавшейся стихии.Читать полностью »
Метка «катастрофоустойчивость»
Сказ о том, как сервер Dell PowerEdge ураган Сэнди пережил
2013-10-09 в 7:52, admin, рубрики: dell, Блог компании Dell, высокая производительность, Железо, катастрофоустойчивость, серверы, ураган, метки: dell, катастрофоустойчивость, серверы, ураганКурс «DevOps для Интернет-проектов» пройдет 21-22 сентября
2013-09-05 в 6:01, admin, рубрики: chef, devops, linux, vagrant, Блог компании Express 42, катастрофоустойчивость, отказоустойчивость, системное администрирование, метки: chef, DevOps, vagrant, катастрофоустойчивость, отказоустойчивостьDevOps — новый подход, ускоряющий внедрение эффективных решений, повышающий надёжность и безопасность интернет-проектов. Его применяют ведущие технологические компании — от Facebook до 37signals — объединяя для решения задач эксплуатации разработчиков и системных администраторов. Когда взаимодействие таких команд — война, DevOps — решение.
За 2 дня разберём внедрение DevOps на практике. Научим устанавливать окружение сервера за 5 минут, делать выкатку простой и управляемой, настраивать мониторинг так, чтобы он помогал, а не спамил. Объясним, когда использовать облака и CDN, где лучше размещать проект и как не пострадать от падения марсианского корабля на датацентр.
Курс ведут эксперты из Express 42 с 5-летним опытом внедрения DevOps практик в Groupon, КупиКупон, Оверсан-Скалакси, Skype. Теоретические знания закрепляются практикой.
Курс будет интересен техническим руководителям, разработчикам и системным администраторам. Для прохождения курса необходим ноутбук c Mac OS X или Linux и памятью от 4GB.
Риски ЦОД: выбираем месторасположение
2013-08-08 в 12:00, admin, рубрики: Блог компании Группа Компаний ХОСТ, ГК ХОСТ, ит-инфраструктура, катастрофоустойчивость, надежность, отказоустойчивость, проектирование, цод, энергоэффективность, метки: ГК ХОСТ, катастрофоустойчивость, надежность, отказоустойчивость, проектирование, цод, энергоэффективность «Избежать катастрофы может только тот, кто считает ее возможной».
В. Швебель
Мы все больше зависим от достижений прогресса: читаем почту в кинотеатрах, отмечаем места своего присутствия в foursquare. И бизнес стал не менее зависим от технических достижений. И если для нас поломка телефона становится небольшим неудобством, то для компаний выход из строя любого элемента ИТ-инфраструктуры оборачивается колоссальными убытками. Один час простоя российского банка, входящего в ТОП-100, равен стоимости автомобиля представительского класса. А теперь представьте, размер убытков и упущенную прибыль, если у корпоративного ЦОД рухнули стены или рядом с ним прорвало теплотрассу. Быстро ли запустятся там сервисы? Сколько времени потребуется для восстановления работоспособности, если нет резервного ЦОДа?
Избежать такой катастрофы можно, изначально правильно спроектировав ЦОД, обратив внимание на его месторасположение, эффективность применяемых в нем решений, энергоемкость, надежность и окупаемость.
Моя работа — ждать IT-катастрофы
2013-06-13 в 9:28, admin, рубрики: disaster recovery, аварийное восстановление, Блог компании ВымпелКом (Билайн), информационная безопасность, катастрофоустойчивость, непрерывность бизнеса, управление проектами, метки: disaster recovery, аварийное восстановление, катастрофоустойчивость, непрерывность бизнеса 
Лучшее, что может случиться, — это если результаты того, что я делаю, никогда и никому не пригодятся.
Можно сказать, что я профессиональный параноик: моя задача — разрабатывать планы действий на случай чрезвычайных ситуаций и обучать людей грамотно реагировать в таких случаях. Зачем это нужно? Довольно просто — чтобы в случае непредвиденных ситуаций всегда была страховка.
Вот, например, знаете что будет, если землетрясение уничтожит основной московский ЦОД?
- Сработает автоматика и перебросит часть сервисов на другие ЦОДы. Всё то, что было active-active, продолжит работу (это базовые функции сети, вроде звонков и SMS).
- Затем включается базовый сценарий реакции. Сразу после происшествия формируются команды восстановления из специально обученных людей на объекте, имеющих подготовку по всем аспектам работы этого объекта. Например, из инженера на смене, охранника, системного администратора и так далее. Они бросают все свои текущие дела и занимаются только восстановлением.
- В течение первых 10 минут «бронзовая» команда восстановления анализирует ситуацию. На 11-й минуте руководитель команды докладывает команде более высокого уровня («серебряной», как правило, не присутствующей на объекте), например, главному инженеру и руководителю подразделения.
- «Серебряная» команда принимает решение на своём уровне. В нашем случае проблема явно особенно важная, поэтому команда связывается с «золотой» командой — руководителями самого высокого уровня. На принятие решения о том, что ситуация является чрезвычайной, уходит ещё 10 минут (это очень быстро). В течение ещё 5 минут активируются составленные нами планы аварийного восстановления.
- Руководители «бронзовых» команд собирают людей и идут восстанавливать, что могут, на месте. Параллельно собирается кризисный комитет, включающий известных специалистов, описанных в плане на этот случай.
- Далее кризисный комитет взаимодействует с HR, PR, безопасниками и другими службами. В частности, совершенно точно PR к этому моменту будет остро нуждаться в информации — абоненты уже полчаса без мобильного из интернета, нужно выступить с данными о сроках восстановления.
- Разворачивается резервная точка. В течение 20-30 минут восстанавливается инфраструктурный слой. Затем идет восстановление СУБД и там, где надо, восстановление из архива с ленты. Далее — восстановление приложений (от получаса до дня).
- Параллельно в течение первого часа проверяется, как всё переехало.
- Затем появляются детальные отчёты. План аварийного восстановления заканчивается, и мы снова «засыпаем» до следующей ситуации.