Как стать автором
Обновить

Компания WiseOPS временно не ведёт блог на Хабре

Сначала показывать

Мы хотим, чтобы серверы падали одновременно

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров17K

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

Сервера, которые смущали заказчика работали в роли бэкенда для хранения видеофайлов. По сути, это было множество узлов, содержащих десятки терабайт видеофайлов, которые предварительно были нарезаны в разном разрешении конвертерами. Затем, все эти миллионы файлов отдавались во внешний мир с помощью nginx + kaltura, что позволяло перепаковывать на лету mp4 в сегменты DASH/HLS. Это позволяло хорошо переносить даже высокие нагрузки, отдавая плеером только нужные сегменты без резких всплесков.

Проблемы появились тогда, когда встал вопрос с георезервированием и масштабированием при росте нагрузок. Сервера внутри одной группы резервирования умирали не синхронно, так как представляли были весьма разнообразным зоопарком с разными провайдерами, шириной канала, дисками и RAID-контроллерами. Нам предстояло провести аудит всей этой красоты и перестроить почти с нуля весь мониторинг с методологией управления ресурсами.

Читать далее
Всего голосов 41: ↑39 и ↓2+56
Комментарии36

Как я собрал красивое ведро для гидропоники

Уровень сложностиПростой
Время на прочтение10 мин
Количество просмотров27K

Несколько лет назад я писал пост о том, как вырастить на гидропонике крайне острый Trinidad Scorpion CARDI. Он, при его живительных 1.2 миллионах единиц Сковилла, на неподготовленных перцеедов производит впечатление эквивалентное облизыванию паяльника.

Пока Монстр плодоносил и радовал в течение нескольких лет, я продумывал более удобный вариант гидропонной установки, который было бы не стыдно показывать в приличном интерьере гостям. Классический вариант “юного гидропониста” из канализационных труб, алюминиевого скотча и вороха булькающих трубочек был с негодованием забракован женой. Я разработал и протестировал несколько прототипов с 3D-печатными элементами, но потом проект был поставлен на паузу.

Окончательно доделать его получилось после того, как внезапно выяснилось, что коллеги тоже фанаты острого. Мы собрались в нашей виртуальной “курилке”, запилили проект со всеми положенными milestone в Asana и начали тестировать. Садитесь поудобнее, сегодня будет лонгрид-оффтопик, про то, как толпа DevOPS из WiseOPS пилила совместный хобби проект для украшения офиса. Да, мы заняты не только работой) А еще я поделюсь подробной инструкцией и файлами для 3D-печати.

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

Читать далее
Всего голосов 110: ↑109 и ↓1+132
Комментарии166

Disaster Recovery Plan: Как правильно заваривать чай, когда горит серверная

Уровень сложностиПростой
Время на прочтение9 мин
Количество просмотров8.2K

Компания у нас на full-remote, поэтому заседание кружка параноиков мы проводим как-то так. Иногда под банджо в углу.

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

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

Макаки жуют провода. Цикады принимают кабели за ветки, и расковыривают их, чтобы отложить внутрь яйца. Акулы жуют трансатлантические кабели Google. А в топе источника проблем для крупной телекоммуникационной компании Level 3 Communications вообще были белки.

Короче, рано или поздно, кто-то обязательно что-то сломает, уронит, или зальет неверный конфиг в самый неподходящий момент. И вот тут появляется то, что отличает компании, которые успешно переживают фатальную аварию от тех, кто бегает кругами и пытается восстановить рассыпавшуюся инфраструктуру - DRP. Вот о том, как правильно написать Disaster Recovery Plan я сегодня вам и расскажу.

Читать далее
Всего голосов 36: ↑36 и ↓0+37
Комментарии43

Hashicorp Vault — собираем непрямую репликацию через ведро

Уровень сложностиСложный
Время на прочтение15 мин
Количество просмотров4.8K

Hashicorp Vault - прекрасный продукт для централизованного хранения всех паролей и других секретов компании. При этом, многие знают, что удобная ключница - это идеальный способ потерять все ключи одновременно. Когда я работал в крупном телекоме, то DRP-протоколы с восстановлением данных учитывали даже запрет на сбор более двух Хранителей Ключей в одном месте. Чисто на случай очень неудачного корпоратива с совместным полетом на воздушном шаре, дегустацией домашних грибов или другими подобными факторами. Короче, если вы внедряете подобную систему, то вам надо очень внимательно подходить не только к вопросам эксплуатации, но и резервного копирования и восстановления.

Сегодня я не буду глубоко касаться темы организации правильного хранения фрагментов ключей Шамира. Вместо этого, я попробую рассказать о том, как развернуть с нуля отказоустойчивый кластер Hashicorp Vault в community edition. Для этого поднимем основной и тестовый кластер Vault в нескольких регионах и датацентрах. Тестовый кластер у нас одновременно будет служить и резервным в рамках процедуры DRP.

Чтобы было совсем интересно, настроим процесс таким образом, чтобы тестовый кластер был односторонней репликой продуктивного с отставанием в несколько суток. Разумеется, все развертывание мы будем проводить в парадигме Infrastructure-as-a-code с Terraform и Ansible в качестве основных инструментов.

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

Читать далее
Всего голосов 22: ↑22 и ↓0+22
Комментарии15

Как я поменял профессию: из тканевой инженерии в adult-индустрию

Уровень сложностиПростой
Время на прочтение11 мин
Количество просмотров63K

Если ты DevOps, который работает с adult‑проектами, то твой типичный «взрослый контент» будет выглядеть примерно так.

Одна из самых традиционных тем на Хабре — это внезапные карьерные перемещения из различных профессий в IT и обратно. У меня, вот, чудесный коллега — профессиональный мясник с соответствующим образованием. Мониторинг настраивает как боженька и умеет убедительно отстаивать свою точку зрения. Образование позволяет.

Меня тоже можете принимать в свои ряды людей со странной сменой профессии. Как многие помнят по моим старым постам — я изначально врач, который свернул в направлении фундаментальной науки и тканевой инженерии. Все вот эти развлечения со стволовыми клетками, выращиванием органов в биореакторах и прочими нетиповыми экспериментальными задачами. И вот тут меня внезапно позвали на собеседование в крупный телеком… Короче, очнулся я уже будучи DevOps в компании, которая занимается сложными проектами, некоторые из которых про adult‑видео. Ну вот те самые специальные обучающие фильмы для взрослых, которые двигатель прогресса. С петабайтами отданного трафика, набегами миллионов пользователей и прочими радостями.

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

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

Предлагаю перейти под кат, а я попробую рассказать, как выглядит вся эта индустрия глазами врача/био‑инженера/DevOps.

Читать далее
Всего голосов 168: ↑159 и ↓9+197
Комментарии164