Прежде чем выкатывать в прод новую фичу или целый продукт, имеет смысл устроить так называемые «учения». Суть этих забав — проверить, насколько быстро и точно команда сможет понять, что система уже в агонии.
На первый взгляд напоминает хаос-тестирование, но под другим углом страдания. Если в хаосе мы проверяем, выдержит ли система вцелом, то тут — насколько весело и с каким количеством паники можно будет выяснить, что конкретно пошло по известному маршруту.
Как это работает? Очень просто: устраиваем контролируемые отказы. К примеру: ⁃ Перестаём слать данные в один из каналов телеметрии ⁃ Забиваем все соединения к БД, как будто пятница и все пошли строить отчёты ⁃ Замедляем или полностью отключаем внешний сервис через какую-нибудь тулзу ⁃ Оставляем один экземпляр бэкенда из десяти ⁃ Ну и другие радости, всё зависит от специфики проекта и ваших SLA
Что происходит дальше? Поначалу, очень часто — ничего. Точнее, внешне ничего. Метрики такие: «всё норм, шеф», алерты мирно спят, в логах тишина. И только редкий вялый WARNING в логах вида «unknown error - operation failed», скромно обозначает, что половина системы уже лежит, а вторая пишет себе завещание. И цель здесь — дотянуть observability до нужного уровня, чтобы алерты орали во всю глотку. Полученные результаты могут быть использованы при организации процесса поддержки и написании соответствующей документации для дежурных админов/разрабов.
Такие учения — это не только способ проверить готовность команды, но и шанс обнаружить серьезные баги (хотя по-хорошему надо бы провести полноценное хаос-тестирование, но и это лучше чем ничего). Потому что если не вы устроите системе праздник жизни — она устроит его сама. В пятницу, в 18:03.
Прежде чем выкатывать в прод новую фичу или целый продукт, имеет смысл устроить так называемые «учения». Суть этих забав — проверить, насколько быстро и точно команда сможет понять, что система уже в агонии.
На первый взгляд напоминает хаос-тестирование, но под другим углом страдания. Если в хаосе мы проверяем, выдержит ли система вцелом, то тут — насколько весело и с каким количеством паники можно будет выяснить, что конкретно пошло по известному маршруту.
Как это работает? Очень просто: устраиваем контролируемые отказы. К примеру: ⁃ Перестаём слать данные в один из каналов телеметрии ⁃ Забиваем все соединения к БД, как будто пятница и все пошли строить отчёты ⁃ Замедляем или полностью отключаем внешний сервис через какую-нибудь тулзу ⁃ Оставляем один экземпляр бэкенда из десяти ⁃ Ну и другие радости, всё зависит от специфики проекта и ваших SLA
Что происходит дальше? Поначалу, очень часто — ничего. Точнее, внешне ничего. Метрики такие: «всё норм, шеф», алерты мирно спят, в логах тишина. И только редкий вялый WARNING в логах вида «unknown error - operation failed», скромно обозначает, что половина системы уже лежит, а вторая пишет себе завещание. И цель здесь — дотянуть observability до нужного уровня, чтобы алерты орали во всю глотку. Полученные результаты могут быть использованы при организации процесса поддержки и написании соответствующей документации для дежурных админов/разрабов.
Такие учения — это не только способ проверить готовность команды, но и шанс обнаружить серьезные баги (хотя по-хорошему надо бы провести полноценное хаос-тестирование, но и это лучше чем ничего). Потому что если не вы устроите системе праздник жизни — она устроит его сама. В пятницу, в 18:03.
BY StringConcat - разработка без боли и сожалений
Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260
Telegram has gained a reputation as the “secure” communications app in the post-Soviet states, but whenever you make choices about your digital security, it’s important to start by asking yourself, “What exactly am I securing? And who am I securing it from?” These questions should inform your decisions about whether you are using the right tool or platform for your digital security needs. Telegram is certainly not the most secure messaging app on the market right now. Its security model requires users to place a great deal of trust in Telegram’s ability to protect user data. For some users, this may be good enough for now. For others, it may be wiser to move to a different platform for certain kinds of high-risk communications. Telegram does offer end-to-end encrypted communications through Secret Chats, but this is not the default setting. Standard conversations use the MTProto method, enabling server-client encryption but with them stored on the server for ease-of-access. This makes using Telegram across multiple devices simple, but also means that the regular Telegram chats you’re having with folks are not as secure as you may believe. You may recall that, back when Facebook started changing WhatsApp’s terms of service, a number of news outlets reported on, and even recommended, switching to Telegram. Pavel Durov even said that users should delete WhatsApp “unless you are cool with all of your photos and messages becoming public one day.” But Telegram can’t be described as a more-secure version of WhatsApp. He floated the idea of restricting the use of Telegram in Ukraine and Russia, a suggestion that was met with fierce opposition from users. Shortly after, Durov backed off the idea. There was another possible development: Reuters also reported that Ukraine said that Belarus could soon join the invasion of Ukraine. However, the AFP, citing a Pentagon official, said the U.S. hasn’t yet seen evidence that Belarusian troops are in Ukraine.
from ye
