• RPO (recovery point objective) – допустимая потеря данных. Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) защиту своих данных от потери выше приемлемого уровня.
  
  
• RTO (recovery time objective) – допустимое время восстановления данных Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) возможность восстановления своей работы в приемлемый срок.

Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.

Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.

Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".

Поскольку блокировки интернета в РФ в последние недели и месяцы многократно активизировались, а маразм все крепчает и крепчает, стоит еще раз поднять тему обхода этих самых блокировок (и делаем ставки, через сколько дней на эту статью доброжелатели напишут донос в РКН чтобы ограничить к ней доступ на территории страны).

Вы, наверняка, помните отличный цикл статей на Хабре в прошлом году от пользователя MiraclePtr, который рассказывал о разных методах блокировок, о разных методах обхода блокировок, о разных клиентах и серверах для обходов блокировок, и о разных способах их настройки (раз, два, три, четыре, пять, шесть, семь, восемь, десять, десять, и вроде были еще другие), и можете спросить, а зачем еще одна? Есть две основные причины для этого.

Методика измерения

> С 10 апреля 2024, 3 месяца спустя,
> данная статья заблокирована РКН на территории РФ,
> но доступна с IP других стран, а также через веб-архив.

На фоне прошлогоднего обострения цензуры в РФ, статьи автора MiraclePTR стали глотком свободы для многих русскоязычных айтишников. Я же хочу приоткрыть дверь к свободной информации чуть шире и пригласить «не‑технарей» («чайников»), желающих поднять личный прокси‑сервер для обхода цензуры, но дезориентированных обилием информации или остановленных непонятной технической ошибкой.

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

Статья рассчитана на «чайников», не знакомых с предметной областью. Однако и люди «в теме» могут найти нечто полезное (например, чуть более простую настройку проксирования через CloudFlare без необходимости поднимать nginx на VPS).

Если у вас ещё нет личного прокси для обхода цензуры — это знак.

Проектирование и работа с REST-сервисами стали повседневными задачами для многих аналитиков. Однако мы часто встречаемся на работе с различными или даже противоречащими друг другу трактовками таких понятий, как REST, RESTful-сервис, RESTAPI.

Сегодня мы разберём, какие принципы вложил в парадигму REST её автор и как они могут помочь нам при проектировании систем.

Выясним, почему существует терминологическая путаница вокруг REST и как нам научиться лучше понимать коллег.

Поговорим о том, как связаны HTTP и REST. А также почему REST противопоставляют SOAP.

Это руководство описывает развёртывание HTTPS-прокси с помощью dumbproxy на практически любом Linux-сервере. Потребуется только curl и рутовый доступ.

Nudecrawler - паук для поиска голых женщин.

Подробный рассказ о том, как я свой дом и сад сделал умными. С фото, техническими деталями, стоимостями и выводами на будущее.

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

И одновременно перфекционист — это ругательство. Это человек, который устроит истерику, пока логотип на сайте не передвинут на 1 пиксель. Как человек, страдавший от перфекционизма, расскажу, когда он несет благо, а когда зло, и как превратить дурной перфекционизм в полезный.

Говорят, в жизни все стоит попробовать хотя бы раз. И если вы привыкли работать с реляционными СУБД, то познакомиться на практике с NoSQL стоит в первую очередь хотя бы для общего развития. Сейчас в силу бурного развития этой технологии очень много противоречивых мнений и горячих споров на эту тему, что особенно подогревает интерес.
Если вникнуть в суть всех этих споров, то можно увидеть, что они возникают из-за неправильного подхода. Те, кто использует NoSQL базы именно там, где они нужны, довольны и получают от данного решения все его плюсы. А экспериментаторы, уповающие на данную технологию как панацею там, где она не применима вовсе, испытывают разочарование, потеряв сильные стороны реляционных баз без приобретения весомых выгод.

Я расскажу про наш опыт внедрения решения, основанного на СУБД Cassandra: с чем пришлось столкнуться, как выкручивались из трудных ситуаций, удалось ли нам получить выигрыш от использования NoSQL и где пришлось вложить дополнительные усилия/средства.
Исходная задача — это построение системы, записывающей звонки в некое хранилище.

Принцип действия системы следующий. На вход приходят файлы с определенной структурой, описывающей структуру вызова. Затем приложение обеспечивает сохранение этой структуры в соответствующие колонки. В дальнейшем сохраненные вызовы используются – для отображения информации по потреблению трафика для абонентов (начисления, звонки, история баланса).

Почему выбрали Кассандру вполне понятно — она пишет как пулемет, легко масштабируема, отказоустойчива.

Принципы Site Reliability Engineering (SRE) в последнее время очень популярны, отчасти благодаря знаменитой книге о SRE в Google, где говорится о золотых сигналах, за которыми нужно следить, чтобы наши системы работали быстро и безотказно в любых масштабах.

Все понимают, что это важные сигналы, но не все знают, как их отслеживать. Об этом всем мы расскажем в данной статье.

Несмотря на то, что мы уже успели достаточно подробно рассмотреть целых шесть сборщиков мусора (Serial, Parallel, CMS, G1, ZGC, Epsilon), у OpenJDK еще есть, что нам предложить. Эта статья посвящена Shenandoah, тому самому сборщику, "который смог" (с таким слоганом он обычно подается).

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

Мне всегда хотелось иметь возможность отлаживать bash-scripts так же, как и любой другой код, т.е. по шагам, и bash такую возможность предусмотрел, но о ней не все знают. Несмотря на довольно большой опыт использования Linux, я дошёл до неё только недавно.