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

Комментарии 38

Время идёт, а компании наступают на всё те же грабли.

Майки уже не те)
Вчера вместе с билдом 19555 в fast ring убили WSL2)
Конечно бета, отказ от ответственности, все дела, но 90% fast ring юзают только из-за WSL.

а у меня 19555 "убил" админские права моей учётки. Точнее я вообще не понимаю что происходит: не запускается ни одно store приложение, ни один msi пакет, пишет типо
Registration data is not valid. Only registered users can start MSI installation. And you must enter registration data into MSI launch script. И в папку store приложений даже зайти нельзя, не то что запустить. Только если руками права на full назначить юзеру. Странный баг… я тоже, конечно, всё понимаю и без претензий, лишь бы след билд это пофиксил. Хотел почитать баги в фидбек хабе, типо мож у кого уже тоже было — да не тут-то было — он тоже не запускается теперь ))) Просто ради любопытства интересно, что же они там такого хорошенько апдейтнули.

Rollback на 19501 вроде, к предыдущему

я жгу мосты удаляю откат сразу после установки, если всё запустилось, а баг я заметил не сразу )) Да не, ну жить можно… так-то обычный установленный софт пашет, новый тока не ставится, продержусь до следующего, а если уж не исправится, буду думать

Секундочку… Они отказались от WSL2 что-ли?
We've initiated the deployment of the updated certificate and are monitoring service health as the fix progresses.
Вместе с сертификатом внедряется служба мониторинга.

Перевод некорректен. Они никакую службу мониторинга не внедряют. Они отслеживают состояние сервиса во время применения исправления.
Так что могут и в следующий раз таким же образом упасть.
Извиняюсь за некомпетентность, что за сертификат такой, что его меняют целых 5 часов? В моём весьма ограниченном понимании это делается максимум за полчаса, даже на продакшене. Или это бюрократия мешается? Никогда не работал в более-менее крупных ИТ компаниях, поэтому и спрашиваю.
НЛО прилетело и опубликовало эту надпись здесь
Тут возникает проблема, когда серверов становится куча, разделены они по разным ДЦ в разных частях света, управляющие ими живут в разных часовых поясах. И всех их надо суметь внезапно скоординировать.
Особенно забавно, например, если CI/CD было с этим же сертификатом, да и управление этой частью софта было по тому же https с тем же сертификатом и теперь брокеры соединений отказываются вас подключать к нужным серверам из-за его некорректности — и приходится разливать сертификат вручную.
НЛО прилетело и опубликовало эту надпись здесь
Да, не подумал, что сервер-то не один, и сложная инфраструктура скорее всего разбросана по частям света. И пул реквест и ревью, как описали выше… В общем, становится ясно, почему так долго чинили.

Ну вы же не знаете их инфраструктуру. Мб у них несколько SSL терминаторов и они не зависят друг от друга + бюрократия. Судя по инциденту и времени исправления — там все плохо.

То что такой инцидент допустили это несомненно большая проблема и её тоже будут решать. А вот, то что на сервис с 20млн активных пользователей и сотнями, а если не тысячами серверов смогли выпустить фикс за 5 часов, это значит что работа команды разработки и развёртывания проделана на отлично. Тимс это не домашняя страничка на ПХП, куда можно просто зайти терминалом, подменить один файлик и перезапустить сервер
Странички конечно ещё существуют, но сейчас на нормальных проектах, нужно всего лишь зайти в Vault, прописать сертификат и если автоматом не подтягивается — нажать кнопку в CI =) 5 часов на такое — это означает:
1. Отсутствие мониторинга и алертов
2. Бюрократия
3. Админов прессуют безопасники
В целом согласен, надо будет почитать их post mortem. Даже если сертфикаты лежат в волте и в случае такого инцидента можно зайти и руками поменять, то так просто всё равно не сработает, т.к. нужно чтобы сервисы перечитали сертификаты, они это делают либо по таймеру, либо при запуске. Значит нужно «нажать кнопку CI», только для тысячи серверов это означает подождать пару суток. Ведь нельзя просто перезагрузить все сервера в один момент, деплой идёт волной, обычно не более 5% сервисов одного типа обновляются, после обновления система ждёт некоторое время, чтобы увидеть зелёный мониторинг. В итоге, полная выкатка релиза на все окружения вполне может занимать несколько дней, это не ручная работа, всё полностью автоматизировано, с проверками и автоматическим откатом в случае проблем. Чтобы выпустить хотфикс за 5 часов и ничего не сломать придётся что-то хитрое сделать

Это внешние SSL терминаторы или балансеры) они очень лёгкие, зачем деплоить тысячи сервисов? 20ый год на дворе, обновить сертификат — 5 минут.

Например потому что, в компании может быть принята политика сквозного шифрования и этот сертификат применяется не только снаружи, но и внутри кластеров
Возможно, но я не представляю зачем такое делать, это внешняя зависимость во внутренней инфраструктуре и геморрой в управлении инфраструктурой.
Внутри кластеров обычно свой CA и self signed серты.

Не удивляюсь, если новый сертификат надо в пяти разных местах прописать, да ещё разными методами. Достаточно вспомнить этот процесс в WAC

По моим наблюдениям сам сервис не работал порядка часа-полутора, но о том что проблема решена сообщили спустя 5 часов.

4-го ноября на https://www.cloudflarestatus.com/ сертификат протух на каком-то из балансировщиков (поэтому сапорт мне сначала показывал, что "у нас всё работает"), так что с кем не бывает :)

Поэтому LetsEncrypt и автоматическое продление сертификата рулит

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

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

НЛО прилетело и опубликовало эту надпись здесь

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

Для микрософтовских сервисов автоматическое продление далеко не всегда доступно.

Например?

WAC

Кстати, удавалось заводить LE и под Windows Server. Но в случае с WAC, да, такой ресурс в паблик лучше не выставлять. Хотя "во второй версии" LE есть возможность получать wildcard сертификаты с помощью txt записи DNS (DNS-01 validation method), так что вполне возможно использование LE и для WAC

Речь не про возможность использования, а про автоматическое продление. И тут всё печально. Более-менее работает с веб-серверами и практически всё.

Интеграции по дефолту нет конечно. Но при желании можно организовать и автопродление, мне думается, если покопать в эту сторону.

Можно, но нужен будет оркестратор

«Комментарий про то, какая крутая штука — автоматизированный перевыпуск краткосрочных сертификатов, как в Let`s Encrypt».

Как из этого


We've initiated the deployment of the updated certificate and are monitoring service health as the fix progresses.

был сделан такой вывод?


Вместе с сертификатом внедряется служба мониторинга
Зарегистрируйтесь на Хабре, чтобы оставить комментарий