Привет, меня зовут Лёша, я работаю в SEMrush в команде SRE, которая занимается обеспечением бесперебойной работы нашего сервиса. Эта история о том, как мы разогнали деплой в 6 раз и сократили затраты на мониторинг в 3 раза. И все это через приручение канареек и самописные инструменты.

Я расскажу, как мы улучшали релизный пайплайн с помощью канареечного деплоя. Так, за пару лет мы прошли путь от «надо бы попробовать» до самописного тулинга.

Вы можете спросить, зачем разбираться с терминологией, если концепция контейнеров выглядит вполне простой и понятной? Однако, довольно часто неверное использование терминов создает препятствия на пути к освоению контейнеров. Например, люди часто считают, что термины «контейнеры» и «образы» взаимозаменяемы, хотя на самом деле между ними есть важные концептуальные различия. Другой пример: в мире контейнеров «репозиторий» означает вовсе не то, что вы думаете. Кроме того, контейнерные технологии – это гораздо больше, чем только docker.



Так что, не владея терминологией, будет сложно понять, чем docker отличается от CRI-O, rkt или lxc/lxd; либо оценить роль Open Container Initiative в деле стандартизации контейнерных технологий.

Сегодня тема мониторинга IT – инфраструктуры и анализа логов набирает все большую и большую популярность. В первую очередь все задумываются о мониторинге событий безопасности, о чем и будет идти речь в данной статье. Несмотря на то, что на эту тему сказано и написано уже довольно много, вопросов возникает еще больше. И поэтому мы решили сделать перевод статьи «Сritical Log Review Checklist for Security Incidents», написанную Anton Chuvakin и Lenny Zeltser, которая будет полезна как для тех, кто только начинает работать с мониторингом событий безопасности, так и для тех, кто имеет с этим дело довольно давно, чтобы еще раз проверить себя, не упускаете ли вы некоторые возможности.

Про автоматизацию общения с клиентами сегодня не пишет только ленивый. Но вот как начать ее использовать на практике — об этом рассказывают редко.

Мы в Just AI понимаем, что автоматизация — это тренд, и знаем, как она может помочь вашему малому и большому бизнесу. И сегодня решили написать увлекательный туториал о том, как с помощью Google таблиц и конструктора ботов Aimylogic можно без труда и без программирования автоматизировать первую линию общения с вашими клиентами, чтобы получить из этого реальную пользу, а не просто создать очередного бесполезного чат-бота.

Заметил за собой, что постоянно записываю всякие мелочи, полезную информацию, просто что-то из буфера обмена прямо в текстовом редакторе. Всегда где-то на фоне висит открытый Sublime Text с кучей вкладок.

И ещё я заметил, что мне удобнее всего структурировать информацию в одном файле используя синтаксис Markdown — приятнее именно исходный текст, а не результат, отображаемый на том же гитхабе.

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

Всё это привело меня к мысли написать что-то вроде своего движка для хранения всей информации в одном месте и в удобном виде. Да-да, есть куча всяких Evernote, каких-нибудь заметок, встроенных в MacOS/iOS и так далее, которые и синхронизируются, и фичи полезные имеют — но, как говорится, хочешь сделать что-то хорошо (для себя), сделай это сам. Да и, как почти любой программист, в любой непонятной ситуации я беру и пишу всё сам. Так вышло и в этот раз.

Все как в жизни.

Предыстория

В классических методологиях роли владельца продукта не было. Впервые роль владельца продукта появилась в Scrum фреймворке. До этого ближайшей по смыслу ролью была роль менеджера проекта в методологии PMI PMBoK. Роль менеджера проекта содержала в себе ряд противоречий и конфликтов интересов:

1. Менеджер проекта отвечал и за команду, и за отношения с заказчиком. К сожалению, интересы заказчика противоречат интересам команды.
2. Менеджер проекта отвечал только за стадию создания продукта. Менеджеру проекта все равно что будет потом, главное закончить в срок проект с нужными свойствами, качеством и уложиться в бюджет.
3. Менеджер проекта не обязан знать как продавать и продвигать продукт. Отсюда — столько провалившихся на рынке, но формально успешных (выполненных в срок и уложившихся бюджет) проектов.

Решая эти проблему, создатели Scrum:

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

Я больше 10 лет работаю с / в / для agile в сфере web-разработки. Из них больше всего пришлось иметь дело с самым популярным agile фреймворком — scrum (по данным VersionOne). Хочу поделиться с вами накопленными наблюдениями и выводами.

Начну с метафоры, так как иногда приходилось видеть внедрение scrum по такому сценарию:

• До scrum: «разработка» как младенец — она целеустремленна, но не умеет нормально ходить, а очень хочет научиться, чтобы добираться до цели.
• Внедрение: приходит учитель (scrum тренинги, курсы, agile coach и т.п.) и показывает, как ходить. Малыш счастлив, он двигается шагами! Топ-топ-топ. У нас спринты — мы ходим!
• После внедрения: терпеливые стейкхолдеры говорят: «Окей, погнали к цели», на что получают «не давите на команду, мы ходим!». Разработка выписывает интересные траектории и получает удовольствие от процесса, но цель забыта.
• Scrum-но: дальше пилюля правды от бизнеса, scrum «мутирует» и позволяет бизнесу получать какой-никакой продукт от разработки. И, к сожалению, формально ставится галочка «мы работаем по scrum», а реальный потенциал команды разработки так и не раскрыт, да и кругом говорят «scrum ненастоящий».

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.

Ого! Как много информации.

Сегодня очень многие в разработке используют ревью кода. Практика полезная, нужная. Даже если вы не делаете ревью, вы наверняка знаете, что это такое.

На рынке есть куча инструментов для ревью кода с готовыми сценариями использования, рекомендациями и правилами. GitHub, Phabricator, FishEye/ Crucible, GitLab, Bitbucket, Upsource — список можно долго продолжать. Мы в Badoo тоже в своё время с ними работали: в своей предыдущей статье  я рассказывал нашу историю ревью кода и о том, как мы пришли к изобретению собственного «велосипеда» — решения Codeisok.

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

Именно поэтому другую часть айсберга можно и не заметить.

Привет Хабр!

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

Любая система, состоящая хотя бы из двух компонентов (а если у вас есть и PHP, и база данных, то это уже два компонента), сталкивается с целыми классами рисков во взаимодействии между этими компонентами.

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

Наш бэкенд — это PHP-монолит, взаимодействующий со множеством сервисов (самописных из них сейчас порядка пятидесяти). Между собой сервисы взаимодействуют редко. Но проблемы, о которых я говорю в статье, также актуальны для микросервисной архитектуры. Ведь в этом случае сервисы очень активно взаимодействуют друг с другом, а чем больше у вас взаимодействия, тем больше у вас проблем.

Рассмотрим, что делать, когда сервис падает или тупит, как организовать сбор метрик и что делать, когда всё вышесказанное вас не спасёт.

Действующие лица (Команда): разработчиков – 2 человека, админ – 1 человек.

Статья повествует об использовании таких технологий, как Ansible, Docker Swarm, Jenkins и Portainer для реализации CI/CD-пайплайна с возможностью контроля за ним с помощью красивого веб-интерфейса.

Вступление

Чего обычно хочет разработчик? Он хочет творить, не думая о деньгах, и максимально быстро видеть результаты собственного творчества.

С другой стороны, есть бизнес, который хочет денег, да побольше, и поэтому постоянно думает о снижении времени вывода продукта на рынок. Другими словами, бизнес мечтает об ускорении получения MVP (a.k.a. Minimum Viable Product) в новых продуктах или при обновлении существующих.

Ну а чего же хочет админ? А админ – человек простой, он хочет, чтобы сервис не падал и не мешал играть в Кваку Танки и чтобы его пореже дергали разработчики и бизнес.
Поскольку для реализации желаний админа, как показывает правда жизни, его силами должны реализоваться и мечты других героев, представители ИТ-тусовки много работали над этим. Часто получалось достичь желаемого, придерживаясь методологии DevOps и реализуя принципы CI/CD (Continuous Integration and Delivery).

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

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

Теперь пришло время заняться синдромом запястного канала и, одновременно, снять проявление синдрома локтевого канала.

Вы можете продолжить чтение только в том случае, если подготовились провести 15-20 минут, выполняя движения из ситуаций урока. Нет смысла прочитать инструкции, отписаться в комментариях: «подход крутой, однако ещё нет возможности его попробовать – может быть, завтра или в выходные…» Или: «что не делал – эффекта нет, у меня …, какое ваше мнение по этому вопросу. Спрашиваете какой эффект от урока в статье? – не было эффекта – урок пока не делал».

Люди, эффективно использующие знания, точно такие же, как и вы, просто они, обучаясь, что-то увидели внутри себя. Под катом расположен именно такой урок.

Существует несколько популярных securty дистрибутивов, содержащих большинство популярных утилит и приложений для проведения тестирования на проникновение. Обычно они основаны на существующих Linux-дистрибутивах и представляют из себя их переработанные версии. В этой статье будут представлены наиболее известные из них.

Пожалуй, каждый из нас слышал о ком-то, кто «заработал на бирже», «поднялся на торговле на фондовом рынке» и т.д. Действительно, работа с фондовыми инструментами в качестве частного инвестора — один из способов получить доход. Разумеется, с долей риска. И наверняка кому-то хотелось посмотреть изнутри, как всё работает и правда ли перед глазами не спящего днями и ночами начинающего инвестора бегут сотни графиков и цифр.

Совсем недавно БКС запустила в режима бета-теста первый в России простой и удобный сервис для торговли — приложение «Мой брокер». Специально для Geektimes мы попросили бывшего частного инвестора протестировать систему с позиций его опыта, поделиться впечатлениями и заодно немного рассказать о своём пути на фондовый рынок. Передаём ему слово.

Так уж сложилось, что Firefox использует однопроцессную модель, и реальность такова, что такой подход с учётом динамики развития сети и частичной связки с XUL вызывает, мягко говоря, много неудобств. Один процесс должен обрабатывать несколько потоков, что очень сильно сказывается на производительности браузера в целом. Отзывчивость Firefox оставляла желать лучшего, когда тот же Google Chrome прекрасно рендерил тяжёлые страницы, что никак не сказывалось на производительности других вкладок.

Такое положение вещей заставляло многих переходить на хром, а кто не хотел — искал пути решения в виде разного рода оптимизаций, которые по большому счёту из-за нелогичного подхода распределения потоков или банального желания настрочить что-то в блог просто усугубляли ситуацию. Теперь один процесс должен был не просто работать, а очень быстро работать! В конечном итоге и разработчики сами прекрасно понимали, что одно дело — мало памяти, другое — низкая скорость работы, которая в основном оправдана старыми связками с XUL. На деле: открываем в Firefox несколько вкладок сразу, скролим их и в момент загрузки видим, что все тормозит — ни о каком плавном серфинге речи быть не могло.

Мы в «Латере» занимаемся созданием биллинга для операторов связи. В блоге на Хабре мы не только рассказываем об особенностях нашей системы и деталях ее разработки (например, обеспечении отказоустойчивости), но и публикуем материалы о работе с инфраструктурой в целом. Разработчик и системный архитектор Михаель Виттиг (Michael Wittig) написал в блоге Cloudonout интересный материал о наиболее распространенных ошибках при работе с сервисом AWS (Amazon Web Services). Мы представляем вашему вниманию основные тезисы этой заметки.

В один прекрасный момент для одного из проектов появилась необходимость в хранении, обработке и визуализации большого количества логов. Необходимо было индексировать около 10-20 тысяч запросов в секунду с пиками до сотни тысяч, что, как оказалось, является нетривиальной задачей. Для решения этой проблемы мы решили использовать уже знакомый многим ELK- стек. Единственным вопросом было — «а потянет ли он». Как оказалось, потянет, но не сразу.

Специалисты по безопасности из компании Foxglove Security сумели объединить несколько уязвимостей операционных систем от Microsoft, самой старой из которых уже 15 лет. Систему из трёх уязвимостей, собранных в одну, назвали «Hot Potato». Эта система позволяет за разумное время поднять привилегии процесса с самого нижнего до системного, и получить тем самым контроль над ОС.

Среди используемых уязвимостей — NTLM relay, атака на протокол аутентификации NT LAN Manager (конкретно HTTP->SMB relay). Другая уязвимость — «NBNS spoofing», позволяющая атакующему настроить поддельные прокси в Web Proxy Auto-Discovery Protocol. Все уязвимости работают в Windows 7, 8, 10, Server 2008 и Server 2012.


Как утилита работает в Windows 7

Используемые уязвимости не новы. Более того, все они хорошо известны внутри компании Microsoft. Проблема лишь в том, что исправление этих уязвимостей невозможно без нарушения обратной совместимости разных версий операционных систем. Поэтому разного рода хакеры эксплуатируют их по сию пору.

Исследователи взяли за основу своей системы метод 2014 года от Google Project Zero, а затем расширили и дополнили его. Новинкой является метод комбинирования известных уязвимостей между собой.

Скриншот рабочего стола Remix OS для PC (кликабельно)

Разработчики Remix OS выпустили альфа-версию этой операционной системы для PC. Эта Android-совместимая операционная система изначально предназначалась для Remix Mini, компактного системного блока. Система приспособлена для работы с мышью и клавиатурой вместо сенсорного экрана, поддерживает многооконность и панель задач.

Краудфандинговая кампания по сбору средств на системный блок Remix Mini не только успешно набрала необходимую сумму, но и многократно превысила её: в октябре 2015 года итоговая сумма составила боле $1,6 млн. вместо $50000, на которые изначально нацелились создатели Remix — китайский стартап Jide, основанный бывшим сотрудником Google.

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