Довольно часто в последнее время на разных форумах и чатах люди жалуются, что когда они пользуются VPN или прокси, то у них после подключения на устройствах как-то странно начинают работать некоторые приложения. Например, не приходят сообщения в WhatsApp, не загружаютя сторис в Instagram, и другие подобные вещи. Причем нередко проблема чинится сама по себе спустя 10-15 минут после подключения, но после переподключения или переоткрытия клиента начинается снова. Иные жалобы состоят в том, что не смотря на то, что пользователь выходит в интернет через VPN или прокси, некоторые заблокированные сервисы и сайты у него все равно не открываются. И в том и в том обычно винят баги прокси/VPN-клиентов, администраторов серверов, и кого угодно еще. И я вам скажу: зря. Все гораздо проще и гораздо сложнее одновременно.

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

Но кое о чем мы не поговорили. Во второй статье я вскользь упомянул самую передовую и недетектируемую технологию обхода блокировок под названием XTLS-Reality, и пришло время рассказать о ней поподробнее, а именно - как настроить клиент и сервер для нее.

Кроме того, что этот протокол еще более устойчив к выявлению, приятным фактом будет и то, что настройка сервера XTLS-Reality гораздо проще, чем описанные ранее варианты - после предыдущих статей я получил довольно много комментариев типа "А что так сложно, нужен домен, нужны сертификаты, и куча всего" - теперь все будет гораздо проще.

В серии статей по теме DevOps мы вместе с Lead DevOps инженером департамента информационных систем ИТМО Михаилом Рыбкиным рассказываем о проверенных инструментах выстраивания инфраструктуры, которыми с недавнего времени пользуемся сами. В предыдущих статьях мы уже рассмотрели предпосылки перехода на новую инфраструктуру, познакомились с азами Kubernetes и обсудили методы доставки кода. В рамках последней темы мы пришли к методологии GitOps, при которой конфигурация кластера описана декларативно и есть ровно один источник правды ― git с его историей версий и т. д. Но git не является достаточно доверенной средой для хранения секретов ― с его помощью мы не смогли бы обеспечить разделение доступов и т. п. Так что в следующей статье цикла мы рассказываем о том, как можно реализовать отдельное хранилище секретов, без которого полноценно перейти на GitOps невозможно.

Если у вас есть продукт, то у вас есть обязательства перед конечными пользователями. В этом случае SLA (соглашение об уровне обслуживания) — это отличный инструмент. Он помогает сфокусировать внимание разработчиков продукта на том, что больше всего нужно вашим клиентам.

Перевели статью, автор который делится практическими советами при создании SLA. Они помогут лучше понять эту задачу. Автор касается вопросов: что измерять, как измерять где и, самое главное, какие целевые пороги установить.

Приветствую, коллеги.

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

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

Итак, представим, что у нас имеется некоторое количество приложений, которые изначально “не обучены” отдавать аналитику в режиме реального времени. Задача заключается в том, чтобы построить систему мониторинга бизнес-показателей с минимальным вмешательством в эти системы.

Существует множество способов решить эту задачу, и как водится, все они обладают своими достоинствами и недостатками. Основное достоинство описываемого способа заключается в очень простой реализации на стороне приложения (с которого есть необходимость получать аналитику). Но если бы мы сейчас разрабатывали все те приложения, которые нужно “научить” делиться аналитикой, то мы бы, наверное, их подружили с брокером сообщений типа Kafka или Rabbit, а внедрять в уже существующие приложения работу с брокером сообщений (особенно, если брокеры очередей сообщений не развернуты в компании) значительно сложнее, чем просто научить приложения писать свои показатели в лог.

Итак, рассмотрим подробно, как устроена предлагаемая система:

В основе системы лежат события, которые генерируют приложения. События сохраняются в лог (stdout, файл,..). Обработчик (сборщик) логов (в режиме реального времени) распознает в логах события приложений и отправляет их в хранилище (БД).

Казалось бы простая задача - переместить логи из пункта А в пункт Б, что тут сложного. Но даже для такой пустяковой задачи придумали множество ПО: как более популярных Rsyslog, Logstash, fluentd, fluentbit, так и менее известных как file.d, недавно принудительно-опенсорснутая Пилорама (спасибо, Яндекс!).

Сегодня хотелось бы поговорить про ещё один из сего семейства - Vector. Так получилось, что в последнее время я достаточно плотно имел с ним дело с разных сторон и собрал хорошую коллекцию "граблей" на любой вкус и цвет. "Перекладывалка" точно интересная, определённо достойная рассмотрения, но имеющая множество, кхм, особенностей. Вот про эти аккуратно разложенные особенности и как с ними жить я и хочу рассказать.

Привет, Хабр.

В одном из проектов, связанных с мониторингом, мы используем Clickhouse, Prometheus, VictoriaMetrics, Grafana, Alertmanager и Vector.dev. Кстати, что общего у всех этих компонентов? Они написаны не на Java – это было одним из требований проекта, но речь ниже пойдет не об этом, а о Vector.dev.

Хорошая статья про Vector.dev есть на Хабре – но мы решили проверить свою карму, затащив Vector.dev в PoC. На текущий момент полет вполне нормальный: используем ограниченное количество source и sink’ов: File, Clickhouse, HTTP, JournalD и, конечно, сам Vector и его логи (немного погоняли kubernetes_logs, кстати, интересный доклад по теме логов Kubernetes был на недавней VK Kubernetes Conf’23).

Оффтоп

Наш рассказ — это гид автостопщика, некое summary тех вещей, которых нам не хватало при знакомстве с Vault. В нем мы сделаем несколько остановок: поговорим в целом про управление секретами, о том, почему мы рекомендуем именно Vault; рассмотрим, как Vault работает; поделимся лайфхаками по работе с секретами и болью о том, чего нам не хватает в продукте.

Про работу на нескольких проектах

Многозадачность в тренде, но еще не у нас
Кто может?
А эффективно?
Сколько брать?
Принципы и рекомендации

По личному опыту удаленки в  малом бизнесе

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

Кому будет полезна статья?

• аналитикам и их руководителям, которые устали от бесконечного потока ad-hoc задач и хотят построить нормальный процесс работы;

• продактам, которые устали от того, что бизнес-заказчики двигают свои задачи вперед и нарушают планы продуктовой команды;

• бизнес-заказчикам, которые недовольны скоростью решения задач и отсутствием прозрачности в процессе их решения.

Автоматизация развертывания стенда Kubernetes

Что бывает когда стандартное и самое распространённое решение по изучению kubernetes по каким то причинам даёт осечку на твоей рабочей машине?

Ты начинаешь пилить свой велосипед конечно! Вот и я напилил. и он даже катается!)

Эта статья о микроменеджменте, его причинах и разрушительных последствиях. Обсудим, какой вред он наносит, подсветим проблемы, с которыми сталкиваются руководители из-за микроменеджмента, и покажем способы  решения. А ещё, справедливости ради, в этом тексте будут примеры ситуаций, когда микроменеджмент всё же может быть нужен и полезен.

Микроменеджмент – это довольно частое явление. Скорее всего, многие из вас с ним сталкивались в прошлом, сталкиваются прямо сейчас или столкнутся в будущем.

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

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

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

В этом посте описан мой топ-25 обязательных инструментов CLI, на которые я привык полагаться. Если тут нет вашего любимого - дайте мне знать в комментариях :)

Рассказываем, как использовать Jenkins CI/CD Pipeline для создания инфраструктуры AWS с помощью Terraform и Ansible. Мы не будем вдаваться в подробности, как настраивать Terraform или тестировать код по мере создания инфраструктуры, так как эти шаги считаются стандартными. Конечный результат — код Terraform, создающий среду AWS с общедоступными подсетями и инстансами EC2 с Ansible Playbook. Когда код помещается в репозиторий GitHub, GitHub Webhook запускает Jenkins CI/CD Pipeline, действия которого зависят от того, куда мы отправляем код — в ветку разработки или основную.