Pull to refresh
811
31.2
Гуменюк Иван @Meklon

Linux админ, врач-исследователь

Send message

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

Причем, DRP может быть не только для IT, но и вообще для любых компаний и процессов. Например, что делать, если вы продаете туристические туры и тут внезапно всю страну закрывают из-за эпидемии. Лучше заранее понимать, кто и что будет делать в такой ситуации.

Похоже на ТЗ для военных ноутбуков

Тогда нужна периодическая поверка как для автоклавов. И надо толстую сталь брать для корпуса

Рис прям идеально звучит в тропиках с насекомыми) Но, в целом, это не самая критичная опция, если его туда засунули не в состоянии "выловил из реки"

Да, переход на резервный ноутбук. После инцидента добавили требование км герметичному хранению в полиэтиленовых зиплоках.

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

Тогда нужно вводить задачу вида налить -240 мл воды, если в чайнике воды больше максимальной отметки.

У моего коллеги ноутбук в Таиланде отказал из-за того, что муравьи внезапно решили его колонизировать.

"Четверо инженеров погибло при попытке устранения аварии в кластере"

Ещё непонятно, что делать, если чайник уже полный.

Хорошая мысль. Но надо будет исключить ситуации вида "Поставил на газовую плиту пластиковый чайник, полный воды"

На должном уровне на это способно очень ограниченное множество людей.

Не поверишь. Лежат черновики. Ещё бы времени чуть-чуть.

Ну, я таки уже две написал за пару недель. Но в IT тематике

Соглашусь отчасти. Но ключевые пакеты имеют фиксированную версию, как тот же Vault. Конфигурация у них будет идентичной. Единственная разница, которая может появиться между средами - версии второстепенных пакетов, которые могли получить мелкое обновление между двумя циклами обновлений. Это не критично.

Но я понимаю вашу мысль насчёт immutable infrastructure. Это тоже отличный подход и один из вариантов.

Нет, процесс snapshot restore идёт непрерывно, а ноды при этом не запечатываются

Нет, не сносим. Обновление идёт в соответствии с рекомендациями вендора.

Начинаем с текстового кластера. Так как он является репликой, то он сразу же позволяет нам провести интеграционное тестирование на том уровне, который требуется заказчику.

После того, как мы убедились в отсутствии регрессий, обновляем продуктивный кластер. Обычно это поэтапное обновление по одной ноде в роли follower с лидером в самом конце. Всё это, конечно, под прикрытием снапшотов на случай, если что-то пойдет не так.

Zero-downtime с Vault невозможен, но в нормальной ситуации переключение занимает сотни миллисекунд.

Потому что надо не просто скопировать файлы сертификатов при первом запуске, но и выполнить аккуратный reload со стороны Vault, послав ему SIGHUP.

Можно разбить на два отдельных таска, но shell все равно нужен.

Да, не слишком изящно. Я тоже не люблю bashansible, о чем и упомянул выше.

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

Для некоторых систем мы это используем.

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

Нет, а в чем целесообразность? Для Vault все равно нужно зашифрованное key-value хранилище, которое будет служить бэкендом. Raft-протокол тут подходит как нельзя лучше. Плюс, с использованием интегрированного хранилища количество точек отказа уменьшается до одного бинарника, по сути.

PostgreSQL тут будет дополнительной сущностью, которую тоже нужно обслуживать.

Information

Rating
157-th
Location
Краснодар, Краснодарский край, Россия
Date of birth
Registered
Activity