Sys.op
VictoriaMetrics — быстрая и масштабируемая СУБД для хранения и обработки данных в форме временного ряда (запись образует время и набор соответствующих этому времени значений, например, полученных через периодический опрос состояния датчиков или сбор метрик).
Сравнение трех самых популярных Managed Kubernetes платформ.
Kubernetes уже стал синонимом оркестрации контейнеров, поэтому каждый облачный провайдер активно разрабатывает под него свои управляемые сервисы. Чтобы выбрать один из них, нужно как следует все изучить и учесть много факторов.
В статье сравним Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE) и Azure Kubernetes Service (AKS).
Приходя в продукт, который развивается больше десятка лет, совершенно не удивительно встретить в нем устаревшие технологии. Но что если через полгода вы должны держать нагрузку в 10 раз выше, а цена падений увеличится в сотни раз? В этом случае вам необходим крутой Highload Engineer. Но за неимением горничной такового, решать проблему доверили мне. В первой части статьи я расскажу, как мы переезжали с Redis на Redis-cluster, а во второй части дам советы, как начать пользоваться кластером и на что обратить внимание при эксплуатации.
Vector, предназначенный для сбора, преобразования и отправки данных логов, метрик и событий. Его Github
Будучи написанной на языке Rust, он отличается высокой производительностью и низким потреблением оперативной памяти по сравнению с аналогами. Кроме того, большое внимание уделено функциям, связанным с корректностью, в частности, возможностям сохранения неотправленных событий в буфер на диске и ротации файлов.
Архитектурно Vector является роутером событий, принимающим сообщения из одного или нескольких источников, опционально применяющим над этими сообщениями преобразования, и отправляющим их в один или несколько стоков.
Vector это замена filebeat и logstash, он может выступать в обоих ролях (получать и отправлять логи), более подробней на их сайте.
Сегодня хочу поговорить о том, как проводить one-to-one встречи.
Сначала о том, зачем они вообще нужны. One-to-one встречи – это один из инструментов развития команды. На этих встречах вы постепенно, планомерное выстраиваете отношения с сотрудником. Прозрачные, ясные отношения, в которых становится возможным сотруднику развиваться. В итоге эти встречи работают на адаптацию сотрудников, на их мотивацию и удержание.
На встрече важно обсудить не только задачи. Вот примерная схема проведения one-to-one встречи.
1. О сотруднике. С этого стоит начать. Спросите, как у него дела, что у него в жизни происходит.
2. Задачи. Какие сейчас у него задачи, какие у них сроки, какие есть проблемы.
3. Мотивация. Важный пункт, не игнорируйте его, пожалуйста. Необходимо прояснять мотивацию сотрудника на каждой встрече. Спросите, как ему его задачи, что нравится, что нет.
4. Компания. Тут вы возвращаете сотрудника к тому, что он часть компании, что он приверженец определённой группы. Поделитесь с ним новостями компании и спросите, как это ему, поделитесь информацией про команду и тоже спросите, как это ему. Таким образом вы закрепляете за человеком его вовлечённость.
5. Работа с тимлидом. Самый неудобный вопрос) Можно задавать в лоб: «Как тебе работается со мной?» или окольными путями: «Что бы ты хотел в нашем взаимодействии улучшить, как тебе one-to-one, что бы ты хотел вынести на one-to-one», и т.д.
6. Кризисы. Если в команде возник конфликт, пертурбация (например, когда из-за вируса все стали работать из дома), не старайтесь делать вид, что ничего не изменилось. Разъясните сотруднику происходящее, спросите, как он чувствует себя внутри всего этого. Вы таким образом можете снизить его тревогу. Сейчас достаточно много вызовов мира, которые заставляют сотрудников поступать по разному. И для нас важно понимать, не останется ли завтра проект без важного сотрудника, по его личным причинам.
На одном из потоков курса «PSYvIT для управленцев» меня спросили, надо ли на каждой встрече говорить про компанию. Разве может отношение к компании меняться раз в неделю? Нет, не обязательно каждый раз, но раз в 2-3 недели спросите. Вопросы могут меняться: держите в фокусе компанию, а спросите про продукт, про новый релиз. Компания – это вообще про окружение сотрудника, про команду. Опять же, многое зависит от того, что в вашей компании происходит сейчас. Кроме вопросов, рассказывайте об успехах и изменениях, которые происходят. Очень важно, чтобы новости компании сотрудники узнавали от вас, а не из новостной ленты социальных сетей.
Чтобы защитить вашу корпоративную сеть от угроз и атак, вы всегда должны выполнять тест на уязвимости в своей системе. Для того, чтобы их исправить. Итак, как вы понимаете, работа с отчетами очень важна для любого SOC, потому что она дает обзор уязвимостей, которые могут быть в вашей системе.
В этой статье мы расскажем вам об инструменте, который мы использовали для создания отчетов и сканирования уязвимостей.
В проектах, связанных с разработкой микросервисной архитектуры, CI/CD переходит из разряда приятной возможности в категорию острой необходимости. Автоматическое тестирование является неотъемлемой частью непрерывной интеграции, грамотный подход к которой способен подарить команде множество приятных вечеров с семьёй и друзьями. В противном же случае, проект рискует быть никогда не завершенным.
Можно покрыть весь код микросервиса юнит-тестами с мок-объектами, но это лишь частично решает задачу и оставляет множество вопросов и сложностей, особенно при тестировании работы с данными. Как всегда, наиболее острые – тестирование консистентности данных в реляционной БД, тестирование работы с облачными сервисами и неверные предположения при написании мок-объектов.
Все это и немного больше решается тестированием целого микросервиса в Docker-контейнере. Несомненным преимуществом для обеспечения валидности тестов является то, что тестам подвергаются те же самые Docker-образы, что идут в продакшен.
Автоматизация такого подхода представляет ряд проблем, решение которых будет описано чуть ниже:
Это статья по мотивам моего выступления на SECR 2019. Так что для тех, кому лень читать, вот запись выступления.
Привет, меня зовут Григорий. Я работаю тимлидом распределённой команды в Positive Technologies. Это мой рассказ, как я стал лидом распределённой команды, с какими проблемами сталкивался, как их решал и какой опыт получил. Мотивами к написанию статьи стали два факта: во-первых, кто-то сейчас может бороться с похожими проблемами, и мой опыт будет полезен, во-вторых, те, кто уже прошёл этот путь дальше меня, могут подсказать, что меня может ждать дальше.
У нас было три небольших группы разработки. Каждая жила по своим правилам, у каждой был свой список задач, свои цели и свой лид, одним из которых был я.
«Важная истина, что вещи не всегда являются тем, чем кажутся, общеизвестна…»
―Дуглас Адамс, Автостопом по Галактике
