Пусть пользу приносит

Ноябрь оказался богат на новые инструменты, такие как Docker с поддержкой Wasm и система управления версиями Sapling*. Ещё сегодня посмотрим на эффективность прогрева VM языков программирования и правильное восприятие инцидентов, о которых сообщили пользователи.

 

Подружим Docker с WebAssembly

Даже суровый бородатый DevOps любит играть в «песочнице»‎. Ведь там есть полная свобода, а ошибки не столь страшны. Можно, не рискуя нервами, проделывать сложные манипуляции и наблюдать, как ведёт себя система. Одна из таких «песочниц»‎ называется Wasm. Её создали, чтобы внутри браузера была безопасная среда исполнения. Вышло ещё лучше.

Сейчас Wasm умеет компилировать приложения более чем на 40 языках и запускать их внутри изолированных окружений. Такие гиганты как Figma и облачный Photoshop добились за счёт этого отличной производительности прямо в браузере.

Но это не предел. Следующим шагом стал выход за пределы браузера с помощью системного интерфейса WASI. Это модульный набор стандартизированных API. Разработчик может выбрать из этого букета именно то, что ему нужно для решения конкретной задачи.

В Docker решили, что Wasm годится на роль удобного дополнения к существующим технологиям запуска контейнеров. Впервые в контексте контейнеризации Wasm был опробован проектом Krustlet. Ну а Docker создали и опубликовали предварительную техническую версию для всех желающих. В containerd добавляется новый вариант запуска в среде выполнения WasmEdge. Работает это примерно так:

docker run -dp 8080:8080 --name=wasm-example --runtime=io.containerd.wasmedge.v1 --platform=wasi/wasm32 michaelirwin244/wasm-example

Флаг --runtime=io.containerd.wasmedge.v1 говорит системе, что мы выбираем WasmEdge вместо стандартной среды исполнения Linux-контейнеров. Второй флаг --platform=wasi/wasm32 конкретизирует, через какой системный интерфейс и на какой целевой архитектуре стартовать. В приведённом примере мы берём написанный код приложения на Rust и запускаем его в качестве контейнера, используя WasmEdge.

Очевидно, впереди ещё много работы по обеспечению безопасности, внедрению многопоточности и сборки мусора. Но решение действительно интересное и заслуживает пристального внимания. Чтобы узнать подробнее о будущем проекта, рекомендуем заглянуть в открытый роадмап.

Прогреваем виртуальные машины

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

Исходя из данных научной работы Edd Barrett, Carl Friedrich Bolz-Tereick, Rebecca Killick, Sarah Mount, and Laurence Tratt. 2017. Virtual Machine Warmup Blows Hot and Cold, OOPSLA (October 2017), лишь 74,7% VM достигло этого состояния. Если взглянуть на процесс запуска и сравнить пары (VM, тест) в 30 процессах запуска, то результат обескураживает. Выяснилось, что нет гарантий, что прогрев сработает как нужно. Устойчивого состояния максимальной производительности достигли 43,5% виртуальных машин.

Хотелось бы внести какую-либо определённость и рассказать о причинах данного явления, но однозначного ответа пока нет. Исследователи создали любопытный инструмент, Krun, который должен был контролировать целую пачку параметров (включая температуру процессора) и запускать тесты лишь при достижении идентичных условий. Одним из таких условий было завершение прогрева. Но и тут кроется засада — а как определить, что прогрев завершился?

Придумать, каким способом тестировать, авторам исследования было сложно. Они использовали разное железо (но без кардинальных отличий) и выключили все дополнительные бустеры, вроде Turbo Boost и Hyper-Threading. Так можно было гарантировать одинаковые условия тестирования.

Спустя 5 лет после публикации оригинальной научной работы, кардинально ничего не поменялось. Напротив, появились дополнительные доказательства, что прогрев виртуальной машины нельзя рассматривать в качестве способа достичь максимальной производительности.

Управляем версиями по-новому

Meta* выпустила в Open-source свой клиент системы версионирования Sapling*, поддерживающий традиционный Git, но с прицелом на более эффективную работу в условиях многократного роста объема хранимого кода.

В монорепозитории Meta* десятки миллионов файлов, и сравнимое количество коммитов / веток. В таких условиях спасает практически любая система версионирования. Это и стало причиной разработки Sapling*. Вместе с клиентом сделали ещё и свою серверную часть плюс виртуальную файловую систему. Их также планируют в будущем сделать общедоступными.

Центральная часть Sapling* — команда Smartlog. Именно она формирует положительный пользовательский опыт, скрывая все неактуальные коммиты и оставляя лишь то, что важно в данный момент. Вы видите состояние «до»‎ и «после»‎ коммита — это даёт осознание, что всё сработало как нужно. Одна команда sl — и вы уже получаете исчерпывающее представление о состоянии репозитория. Есть разработчики, предпочитающие работать не с консолью, а с графическим интерфейсом. Для таких есть команда sl web, запускающая это же представление в браузере.

Все ошибаются. И тут кроется наиболее неприятная черта традиционных систем управления версиями — найти ошибку и откатить в состояние до того как «Наташ, мы всё сломали»‎ не так просто. Нередко в таких случаях разработчики матерясь удаляют свой репозиторий и заново его клонируют. Этот неправильный паттерн поведения Smartlog ликвидирует за счёт простых команд: sl undo, sl redo, sl uncommit, sl unamend. Ну а sl hide и sl unhide пригодятся для сокрытия и возвращения коммитов к жизни.

Отдельно отметим sl undo -i (работает в Mac и Linux), которая позволяет прокручивать предыдущие состояния репозитория и возвращать приложение к исходной точке.

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

* Meta Platforms Inc. признана экстремистской организацией и запрещена в России

Узнаём о проблемах от клиентов

«Мы должны знать о проблемах до того, как о них узнают клиенты»‎ — эта установка часто звучит на совещаниях в самых разных компаниях. Но так ли плохо, если вы узнаёте о проблеме не из системы мониторинга, а при обращении клиента в саппорт? Давайте разбираться.

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

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

Недавно Роберт Росс (Robert Ross), соучредитель и CEO в компании FireHydrant, профильно занимающейся управлением инцидентами опубликовал крутой кейс из собственного опыта. Они решили задействовать платформу Spinnaker, а данные обо всех развёртываниях хранить в Redis. Всем этим добром рулил Jenkins.

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

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

Интересно посмотреть

Пропустили наш предыдущий DevOps-митап? Не страшно — записи докладов в кинематографическом качестве выложены в сеть.

Хотите знать, чем Service Desk отличается от Help Desk и как правильно классифицировать инциденты по категориям? Советуем посмотреть следующий доклад:

Непрерывный рост количества данных требует грамотного использования средств автоматизации. Это привело к появлению набора практик с названием DataOps. Предлагаем взглянуть на практическое применение DataOps на примере компании Учи.ру:

Вакансии