Релизы

Спустя три года после начала разработки опубликован релиз Sequoia 1.0. Это реализация OpenPGP на языке Rust, содержащая обширную библиотеку функций и инструментарий командной строки. Релиз опубликован после того, как разработчики закончили работу над низкоуровневым API в нем как раз и реализован в полной мере стандарт OpenPGP.

Написано все это на Rust, а распространяется пакет под лицензией GPLv2+. Есть версии для всех основных платформ Linux, FreeBSD, Windows, macOS, Android и iOS. Команда разработчиков небольшая, ее основа три участника разработки GnuPG из компании g10code. Эта же команда создала и сервис ключей Hagrid, который применяется в сервисе keys.openpgp.org. О том, что представляет из себя пакет под катом.

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

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

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

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

Sequoia также развивает утилиту командной строки sq с поддержкой субкоманд в стиле Git, программу sqv (замена gpgv) для верификации отсоединённых цифровых подписей (detached signature), утилиту sqop (Stateless OpenPGP CLI) и библиотеку sequoia-openpgp. Разработчики предусмотрели обвязки для языков C и Python.

В новом релизе поддерживается подавляющее большинство возможностей, характерных для стандарта OpenPGP, включая шифрование, расшифровку, создание и проверку цифровых подписей. Что касается расширенных возможностей, то добавлена поддержка верификации по отдельно поставляемым цифровым подписям (detached signature), адаптация для интеграции с пакетными менеджерами (APT, RPM, cargo и т.п.) и возможность ограничения подписей по пороговым значениям и времени.

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

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

Релиз 1.0 теперь охватывает crate-пакет sequoia-openpgp и утилиту для проверки цифровых подписей sqv. А вот CLI-интерфейс sq и высокоуровневые API пока не стабилизированы и дорабатываются. В ближайшем будущем команда разработчиков планирует интегрировать сервисы для хранения закрытых и открытых ключей, добавить поддержку незашифрованных цифровых подписей и возможность использования регулярных выражений для определения заслуживающих доверия подписей.

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



Всем привет! Я представляю бэкенд-разработку курьерской платформы. Поговорить хочу о том, как нам удается, с одной стороны, двигаться быстро, а, с другой стороны, не потонуть в ворохе и потоке проблем и ошибок.

(...) Сейчас у нас в среднем выкатывается по три релиза в день.



Стек технологий, которые мы используем типичен для Java-приложений Маркета. Мы используем 11-ю Java, Spring, PostgreSQL для хранения данных, Liquibase для накатывания миграций и Quartz для регулярных Cron-задач. Конечно, у нас реализовано много интеграций с внутренними сервисами.

Начать я хочу с того, как у нас устроен процесс релиза.

1. Релизы

С самого начала проекта мы живем в парадигме trunk-based development. Чтобы код попал в продакшен, нужно поставить пул-реквест и пройти код-ревью. Причем в пул-реквесте запускаются также и прикоммитные проверки, в первую очередь это юнит-тесты и функциональные тесты.

Среды у нас сейчас только две продакшен и тестинг. Когда код-ревью пройдено и код попал в trunk, запускается вот такой релизный пайплайн.



Дальше я покажу все шаги подробнее.



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



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

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

Конечно, у нас есть ограничения при выкатке релиза. Парадигма trunk-based development диктует то, что не должно быть долго живущих feature branches, и получается так, что в trunk может оказаться незаконченная функциональность.

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

При чем здесь кот Шредингера? Часто новая функциональность в продакшене должна и работать, и не работать одновременно: для каких-то пользователей должна быть включена, а для других все должно работать по-старому. Можно было бы, конечно, поднять отдельный инстанс, бэкенд с новой функциональностью, пустить туда какую-то часть пользователей, а остальных оставить на старых.

Но такой подход звучит дорого.

2. Feature toggles

Поэтому мы пришли к тому, что стали использовать feature toggles. Toggles с английского переводится как переключатель, и это в точности описывает его предназначение.

if (configurationService.isBooleanEnabled(NEW_FEATURE_ENABLED)) {    //new feature here} else {        //old logic}

Можно выкатить код и пока не использовать его в продашкене, например, ждать поддержки фронтенда или же дальше его реализовывать.

Нам очень важно уметь включать-выключать функциональность по отмашке от коллег. Поэтому свой toggles мы сложили в базу.

public class User {    private Map<String, UserProperty> properties = new HashMap<>();    String getPropertyValue(String key) {        UserPropertyEntity userProperty = properties.get(key);        return userProperty == null ? null : userProperty.getValue();    }}

Поскольку функциональность не всегда нужно сразу включать на всех пользователей, сделали feature toggles на пользователя и тоже положили их в базу. Так мы можем точечно включать функциональность, и это дает возможность провести эксперименты. Например, мы делали новую функциональность под кодовым названием Звонки. Это напоминание курьеру о том, что у него скоро доставка. (...) Такая функциональность сильно перестраивала процесс работы курьера, и нам было важно проверить, как процесс летит в реальном времени, в реальной жизни.

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



Конечно, у такого подхода есть минусы. Toggles скапливаются, и здесь ничего не остается, кроме как их убирать. Также увеличивается сложность тестов, потому что проверять свой код нужно во всех режимах работы toggles. Кроме того, toggles лежат в базе, поэтому получается лишний поход в БД. Здесь ничего не остается, кроме как поставить кэш. Какие плюсы мы за это получаем?



Мы получаем возможность спокойно жить в парадигме trunk based development. Также можем проводить точечные эксперименты на пользователях.

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

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

Остался вопрос про деградацию. Мы обслуживаем офлайн-процесс, и в случае любых проблем с ПО нам нужно сделать так, чтобы самая важная часть функциональности работала. Чтобы курьеры могли выдать посылку, выбить чек и понять, куда ехать дальше.

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

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

3. Метрики и мониторинги

Поэтому дальше я хочу поговорить о метриках и мониторингах. Сразу скажу: в этой части мы не будем обсуждать, какие системы сбора и визуализации метрик использовать. Для этого есть опенсорс-решения. У себя для сбора метрик мы используем Graphite и, как и для мониторингов, внутреннюю систему.

Какую информацию мы собираем? На слайд я выписала формальное определение метрик и мониторинга.



Но предлагаю рассмотреть, что это такое, на примере.



Метрика обычно представляется как график, он описывает какой-то параметр нашей системы. А мониторинг это событие, превышение заданного ранее порога и какое-то действие, которое необходимо предпринять при превышении порога.

Какие могут быть действия? Конечно, самое важное уведомить ответственных: написать в мессенджер или позвонить. Реже запустить процесс откатки последнего релиза. У себя в проекте мы такой вариант не используем. Еще есть вариант мониторинга, который мы называем загорается лампочка. Произошло интересующее нас событие, и оно отобразилось в интерфейсе мониторинга. Дальше тоже происходит действие уведомить ответственных или еще что-то.



Мы говорим про Java-приложение, а оно должно быть где-то запущено, будь то контейнеры или железные машины. Ресурсы и в том, и в другом случае для нас конечны, нам нужно понимать, как мы их используем. Наши приложения мы запускаем во внутреннем облаке, облако нам предоставляет всю подобную информацию. Информацию о ресурсах стоит собирать не только на контейнерах, где живет ваше приложение, но и там, где работает ваше хранилище.

На слайде пример, как нам в базе перестало хватать CPU.

Окей, у нас Java-приложение, и, конечно, стоит собирать информацию о состоянии JVM.



Мы используем Spring, поэтому для решения такой задачи хорошо подходит библиотека Spring Boot Actuator. Она добавляет endpoint в ваше приложение, и к этому endpoint можно обратиться по http и получить необходимую информацию о памяти или что-то еще. Окей, приложение запущено. Дальше оно вообще работает или нет? Что с ним происходит? Можно отправлять запросы в это приложение или нет?

@RestController@RequiredArgsConstructorpublic class MonitoringController {    private final ComplexMonitoring generalMonitoring;    private final ComplexMonitoring pingMonitoring;    @RequestMapping(value = "/ping")    public String ping() {        return pingMonitoring.getResult();    }    @RequestMapping(value = "/monitoring")    public String monitoring() {        return generalMonitoring.getResult();    }}

Такие вещи нужно понимать не только нам, но и балансеру. Для этого мы добавляем в приложение контроллер с двумя методами Ping и Monitoring. Рассмотрим вначале Ping. Он отвечает на вопросы, живо ли приложение, можно ли отправлять на него запросы. И отвечает он это в первую очередь не нам, но балансеру. Но мы же используем этот метод для мониторинга того, живо приложение или нет.

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

public enum MonitoringStatus { OK, WARNING, CRITICAL;}@RequiredArgsConstructorpublic class MonitoringEvent { private final String name; private volatile long validTill; private volatile MonitoringStatus status;}

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

public interface ComplexMonitoring { void addTemporary(String name, MonitoringStatus status, long validTillMilis); Result getResult(); //тут можно делать проверку для статусов в MonitoringEvent} 

Получается такой простейший интерфейс мониторинга. Добавить или обновить событие и вернуть текущее состояние мониторинга в оговоренном формате.

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



Как мерить RPS, понятно из названия. Стоит отметить, что хорошо смотреть как общий RPS по приложению, так и по отдельным методам API. А вот с двумя остальными с таймингами и пятисотками все не так понятно. В каждый момент времени может быть много запросов и, соответственно, много времен ответов. Всю эту информацию нужно агрегировать. Для этого хорошо подходят перцентили. Этот термин пришел к нам из статистики.

Чтобы рассказать, что это такое, на слайде есть нижний график, на нем выделена точка в 400 мс. Это график 99 перцентиля какого-то метода из нашего API. Что значат эти 400 мс? Что в этот момент 99% запросов отрабатывали не хуже 400 мс.

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

Как мы собираем RPS, тайминги и пятисотки? Когда запрос оказался у нас в инфраструктуру, он попадает на L7 balancer. А дальше он не сразу попадает в приложение, перед этим есть nginx.



А вот уже из nginx он попадает в приложение. У nginx есть access.log, в который можно собирать всю необходимую информацию. Это коды ответа, время ответа и сам запрос.



Часто, когда возникают проблемы с временем ответа или пятисотки, стоит посмотреть, что в это время было с хранилищем.

У нас PostgreSQL, поэтому мы именно его мониторим и смотрим. Мы строим все эти графики не сами они нам предоставляются облаком, в котором развернута наша база. Что у нас есть? Количество запросов, транзакций, лаг репликации, среднее время транзакции и так далее. На самом деле на этих графиках представлен факап, который у нас произошел.



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

Осталась статистика по хранилищу. Хранилище вообще может многое рассказать о состоянии нашей системы. Можно считать показатели: как, например, количество заказов за день, так и просто попадание в интервал доставки. Можно искать противоречия статусной модели. Так мы отслеживаем чеки, с которыми возникли проблемы.

public class MetricQueryRealJobExecutor { private static final RowMapper<Metric> METRIC_ROW_MAPPER = BeanPropertyRowMapper.newInstance(Metric.class); private final JdbcTemplate jdbcTemplate; public void doJob(MetricQuery task) { List<Metric> metrics = jdbcTemplate.query(task.getQuery(), METRIC_ROW_MAPPER); metrics.forEach(metric -> KEY_VALUE_LOG.info(KeyValueLogFormat.format(metric)) ); } @Data private static class Metric { private String key; private double value; }} 

Но далеко не всегда на такие мониторинги должна реагировать разработка. Очень часто на них вначале нужна реакция бизнеса. Вообще задача получения статистики по хранилищу выходит однотипной. Нужно сходить в базу, рассчитать статистику, а результат записать в key-value-лог. Поэтому мы сделали обертку для таких задач.

Сложили в базу такую тройку: уникальный ключ для метрики, сам запрос, в котором можно эту метрику посчитать, и Cron-выражение, когда считать. То есть в базе получилась тройка: ключ запрос cron expression. А над всей этой тройкой сделали Cron-задачу, которая достает ее из хранилища и добавляет к общему пулу Cron-задач. Дальше эта задача выполняется.

Итого, что мы получаем?

• Плохой код не должен попадать в продакшен, для этого мы ставим всевозможные преграды: тесты, стрельбы, мониторинги. Задача без тестов не считается сделанной. Лучше заниматься оптимизацией работы тестов, чем получить проблему в продакшене.
• Feature toggles помогают нам управлять логикой работы бэкенда, а мы, в свою очередь, можем легко управлять toggles, и их плюсы все-таки перевешивают минусы.
• Мы должны уметь быстро обнаруживать проблему, в идеале раньше, чем ее заметят наши пользователи. Но ее мало обнаружить, нужно еще ее интерпретировать. Поэтому собирайте много метрик о состоянии системы. Это помогает в поиске проблемы.

И, конечно, давайте будем писать код без багов, тогда у нас вообще все будет хорошо. На этом у меня все.

Языков программирования в мире много около 8 тысяч, если учитывать вообще все, что может считаться языком программирования, включая всякие шуточные и теоретические проекты. На днях вышла версия 1.0 еще одного языка Crystal.

Его создатели утверждают, что язык является простым, как Ruby, и быстрым, как С. Назвать его новым нельзя, поскольку разрабатывается он с 2011 года, именно как альтернатива Ruby. Авторы проекта заявляют, что язык теперь готов к использованию в обычных условиях, и является стабильным.

Что это за язык такой?

Если вы не слышали о проекте раньше, то вот краткое его описание. Crystal это высокоуровневый объектно-ориентированный язык программирования. Его синтаксис очень похож на синтаксис Ruby, но отличается от своего конкурента тем, что компилируется в машинный код посредством LLVM.

По словам разработчиков и сторонних компаний, которые уже протестировали язык, производительность приложений, написанных на Crystal сравнима с приложениями на С. Последний считается более сложным для освоения, чем Ruby. Таким образом, создатели Crystal убивают сразу двух зайцев дают возможность писать быстрые приложения, и обеспечивают низкий порог входа в разработку.

Что особенного в Crystal?

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

При этом язык не нуждается в указании конкретных типов переменных либо аргументов метода. Дело в том, что компилятор выводит их самостоятельно при помощи специализированного механизма. Разработчики предусмотрели проблему автоматического управления памятью за счет использования консервативного сборщика мусора (garbage collector) Boehm GC. Язык поддерживает как макросы, так и дженерики, плюс способен работать с перегрузкой методов и операторов.

Преимущество Crystal в том, что он, как и Ruby, предлагает независимую от ОС реализацию многопоточности. Легковесные потоки в Crystal называются волокнами (fibers). Потоки, как и в языках Go и Clojure, могут взаимодействовать друг с другом посредством каналов, без необходимости прибегать к использованию общей памяти либо же блокировкам.

В Crystal реализован интерфейс вызова функций из библиотек языка С. При этом синтаксис взаимодействия простой соответственно, с использованием Crystal можно создавать библиотеки-обертки, без необходимости писать код с нуля.

Стандартная библиотека языка представляет широкий спектр типовых функций, включая средства для обработки CSV, YAML, и JSON, компоненты для создания HTTP-серверов и поддержки WebSocket. В процессе разработки предлагается использовать команду crystal play которая формирует web-интерфейс (по умолчанию localhost:8080) для интерактивного выполнения кода на языке Crystal.

Что изменилось с релизом 1.0?

Изменений не так много, но их можно назвать критически важными.

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

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

• HTTP::Request,
• HTTP::WebSocket,
• HTTP::LogHandler,
• URI#full_path,
• Time::Span#duration.

В-третьих, разработчики изменили принцип обработки cookie. В финальном релизе метод HTTP::Cookies.from_headers разделен на отдельные серверную и клиентскую версии. Соответственно, значения и имена файлов не кодируются/декодируются из соображений безопасности.

Есть и изменения, которые уже внесены, но пока что не поддерживаются официально. В их числе многопоточность, которая активируется в среде с многоядерным процессором при помощи флага -Dpreview_mt, поддержка ОС Windows и процессоров с архитектурой ARM.

Есть и несколько менее значительных изменений:

• В строковых и символьных литералах запрещено использование суррогатных сокращений в escape-последовательностях Unicode, таких как "\uD834". Для кодирования произвольных значений следует использовать нотацию "\x".
• Метод округления по умолчанию изменен на TIES_EVEN (округление банкира, до ближайшего целого, а для пограничных ситуаций до ближайшего четного числа). В Number#round добавлен параметр RoundingMode, позволяющий выбрать метод округления. Среди доступных методов: TIES_EVEN, TIES_AWAY, TO_ZERO, TO_POSITIVE, TO_NEGATIVE.
• В коллекциях обеспечена работа Enumerable#flat_map и Iterator#flat_map с элементами смешанных типов.
• При сериализации последовательностей Enum теперь используется представление в форме строк с подчеркиванием.
• Типы, определенные в модуле XML, переведены с использования struct на class.

Ну и немного истории

Как и говорилось выше, разработка языка началась еще 10 лет назад. Авторы проекта основатели аргентинской компании Manas Technology Solutions. Изначально язык назывался Joy, а компилятор для него был создан на Ruby. Чуть позже, в 2013 году, он был переписан уже на Crystal.

Официальная версия языка была выпущена в 2014 году. С течением времени Crystal стал проектом с открытым исходным кодом, который распространяется на условиях лицензии Apache License 2.0.

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

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

Наш проект представляет собой систему дистанционного обучения (LMS, Learning Management System), которой пользуются более 7 миллионов человек в разных странах мира. В системе 1000+ веб-страниц и порядка 10 000 тест-кейсов.



Сейчас в проекте работает около 15 команд разработки со стороны заказчика в Норвегии и со стороны Аркадии в России. Я присоединилась к проекту 8 лет назад в качестве QA; последние 2 года я работаю в качестве QA lead, участвуя в оптимизации процесса тестирования.

Что входит в понятие оптимального процесса

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

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

Процесс разработки в целом:

a) Подход к разработке, удовлетворяющий нужды команды
Мы работаем, используя Scrum и спринты продолжительностью 3 недели. Перед спринтом проходит презентация его целей и формируется набор требований для данного спринта. Далее идет планирование, на котором мы оцениваем все задачи и определяем набор задач, который войдет в спринт. По окончании спринта проходит Sprint review, на котором мы демонстрируем все выполненные задачи и анонсируем достигнутые цели. Такой подход для нас является оптимальным: за спринт мы успеваем сделать достаточное количество новой функциональности и при этом исправить и протестировать определенное количество багов от конечных пользователей на такие баги выделяется 10% времени спринта.



Состав команды: team lead, разработчики, тестировщики. Соотношение разработчиков к тестировщикам в наших командах 3:1. Такое соотношение дает возможность достигать цели спринта равномерно нет периодов, когда кто-то из участников процесса простаивает: пока разработчики делают какое-либо изменение, тестировщики создают или обновляют тест-кейсы, относящиеся к этому изменению; когда разработка закончена, тестировщики проверяют изменения, а разработчики либо переходят к следующим задачам спринта, либо помогают в тестировании (это бывает необходимо при тестировании масштабных изменений).
Product Owner определяет цели и требования в начале каждого спринта и принимает в конце. Также у каждой команды есть Scrum Master, который помогает решать возникающие проблемы.



Для того, чтобы команда имела возможность проводить различные активности, не относящиеся непосредственно к задачам спринта, а также учитывая различные риски, время, рассчитанное на выполнение задач спринта, составляет 80% от всего рабочего времени команды. То есть 2 часа в день в течение обычного спринта резервируются на коммуникации, различные совещания и семинары, а также исправление багов, найденных в спринте.

b) Четкие требования и хорошее планирование
Для того, чтобы планирование не затянулось, а спринт не стал провальным из-за неизвестных ранее деталей и трудоемких дополнительных изменений, добавленных уже в процессе спринта, мы стараемся брать в спринт только изменения с достаточно ясными и четкими требованиями. Если область проекта, которая касается изменений, неизвестна команде, или в течение планирования возникает много вопросов, на которые Product Owner не может дать ответов, команда может взять в спринт задачу на изучение данной области либо задачу на исследование, результатом которого становятся четкие требования или даже некий прототип.

c) Ретроспективы
Работа над ошибками тоже важна. Это касается как спринтов, так и релизов. Случается, что мы что-то не успеваем, или приходится работать сверхурочно, чтобы успеть в срок например, при необходимости дотестировать релиз (а это дополнительные расходы, которых компании хотелось бы избежать в дальнейшем). Поэтому мы проводим ретроспективы, на которых обсуждается, что было хорошего и плохого в спринте или релизе, и вырабатываются меры для избежания таких ошибок в дальнейшем.

d) Поддержка со стороны менеджмента
Иногда возникают вопросы или ситуации, которые невозможно разрешить на уровне команды нужно менять процесс или привлекать к решению менеджмент компании. Очень важно видеть, что тебе хотят помочь и готовы поддержать в такой ситуации. У нас в компании с этим все хорошо это касается как Аркадии, так и менеджмента со стороны заказчика. Все вопросы обсуждаются и всегда находится решение, удовлетворяющее все стороны.

e) И, на мой взгляд, основополагающее это хорошая коммуникация. И то, что есть у нас в компании, для меня является одним из главных преимуществ комфортной работы доброжелательность, желание идти на компромиссы.
Это касается всех: и каждого члена команды, и Product Owner, и Scrum Master, и менеджмента компании, и многих других участников процесса. Все открыты для вопросов и обсуждений, разработчики советуются с тестировщиками в вопросах требований и вместе решают, как лучше (и с точки зрения разработки, и с точки зрения тестирования) сделать то или иное изменение. Product Owner, в свою очередь, постоянно на связи с командой, оперативно решает все вопросы и всегда старается идти навстречу в достижении целей спринта. Scrum Master всегда готов помочь: найти дополнительные ресурсы (тестировщиков/разработчиков, если они требуются для спринта или для релиза) или подсказать, как лучше организовать спринт по времени.

Процесс тестирования:

a) QA-стандарты (guidelines), относящиеся к написанию тест-кейсов.
У нас в проекте тест-кейсы являются основной детальной документацией по функционалу системы, поэтому им уделяется большое внимание. Для каждого изменения, сделанного командой, пишется новый тест-кейс или обновляется уже существующий.
Раньше, когда система была еще не такой огромной, тест-кейсы писались достаточно детальные, с различными конкретизированными шагами, но сейчас этот подход стал неприемлем на обновление таких тест-кейсов уходит очень много времени. Поэтому мы (QA leads) разработали стандарты, основным требованием которых является написание сценариев тестирования с ожидаемыми результатами вместо детально расписанных шагов в тест-кейсах.

b) QA-стандарты, относящиеся к тестированию в спринтах.
Чтобы каждая команда обеспечивала хорошее качество сделанных изменений, были разработаны стандарты тестирования в спринте.
Основа этих стандартов максимальное покрытие тестированием, куда входит:
Тестирование непосредственно сделанного командой изменения (функционал и при необходимости UI);
Тестирование системы после этого изменения с использованием чек-листа: это обязательные проверки, к которым относятся тестирование доступности для людей с ограниченными возможностями, проверка переводов, проверка существующих данных, тестирование с использованием специальных символов, проверки безопасности, тестирование изменений в мобильном приложении и другие проверки.

c) QA-стандарты, относящиеся к тестированию релизов.
Релизный процесс и стандарты, используемые в нем, более подробно рассмотрим ниже.

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

e) Взаимовыручка тестировщиков, помощь разработчиков.
У нас не очень много тестировщиков (в среднем 1 тестировщик на 3 разработчиков), к тому же время от времени они отвлекаются от задач спринта на тестирование релизов, и времени на всё может не хватать.
В таком случае всегда находится кто-то из тестировщиков других команд с меньшей нагрузкой в текущий момент, кто может помочь. Найти такого тестировщика помогает QA lead или Scrum Master. Кроме того, разработчики могут помочь с тестированием изменений в спринте, если по ним уже написаны тест-кейсы.

f) Коммуникация между тестировщиками.
Для коммуникации используется чат в Microsoft Teams, в котором каждый может задавать вопросы и оперативно получать ответы, а остальные тестировщики при этом узнают актуальную информацию. Также у нас проходят ежемесячные QA-митинги, на которых тестировщики делятся друг с другом текущими задачами своей команды и могут обсуждать любые вопросы подход к тестированию и/или расположение тест-кейсов, касающихся незнакомой для тестировщика области; вопросы по релизу (состав будущей релизной команды, изменение сроков тестирования); дополнительные обязательные проверки, добавленные после пропуска критичного бага в релизе, и т.д.).

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

Чем хороши ежемесячные релизы и как мы к ним пришли: организация процесса тестирования во время релиза

Раньше у нас были квартальные релизы. При таких временных рамках к каждому релизу скапливалось достаточно много изменений, которые были сделаны командами. Такой объем изменений, безусловно, требовал регрессию перед релизом, поэтому для регрессии выделялся отдельный период времени, и к ней подключались все команды. Обычно это занимало около 2 недель, и в регрессии участвовали как тестировщики, так и разработчики команд.

Через какое-то время для регрессии в процессе тестирования релиза стали использоваться автотесты. Не все тесты для регрессии были покрыты автотестами, что-то тестировалось вручную. В целом это сократило время тестирования регрессии, но из-за объемов системы полная регрессия все еще занимала много времени.

Весь цикл разработки выглядел примерно так:



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

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

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

Стабилизация включает в себя:

a) тестирование нового функционала, включенного в данный релиз каждой командой;
b) тестирование критичных областей это проверка основной функциональности главных областей системы (что, очевидно, занимает гораздо меньше времени, чем полный цикл регрессии);
c) тестирование багов, найденных в командных изменениях для данного релиза.

Весь цикл разработки теперь выглядит так:



Рассмотрим, что еще необходимо для подготовки к релизу.

Когда стабилизация закончена и релизный пакет имеет хорошее качество, прежде чем выкатывать его на production, проводится тестирование конфигурации на pre-production окружении. Таким образом Operations практикуются обновлять окружение, а тестировщики проверяют конфигурацию с текущим релизным пакетом до реального релиза.

Можно подумать, что 2 недели подготовки к релизу это слишком много, и на тестирование в спринте остаётся мало времени. Но обычно у тестировщика подготовка к релизу занимает 4-6 дней. Это зависит от:

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

Все тестировщики проекта (включая релизную команду) участвуют в тестировании стабилизации; тестирование конфигурации и непосредственно самого релиза делает только релизная команда.

Общее расписание тестирования релиза выглядит так:



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

С точки зрения организации тестирования для каждого релиза выбирается QA-координатор (кто-то из QA leads). Времени на подготовку к релизу для QA-координатора обычно планируется больше, чем для обычных тестировщиков, так как у QA-координатора больше обязанностей. К ним относятся:

• определение релизной команды и проверка доступности всех ее участников на время релиза;
• подготовка тест-планов для релиза;
• запуск автотестов на этапе стабилизации и тестирования конфигурации;
• координация работы тестировщиков во время тестирования релиза;
• помощь тестировщикам в решении всевозможных вопросов, связанных с релизом;
• контроль за выполнением тестирования и при необходимости перераспределение нагрузки для помощи в тестировании перегруженным командам (это могут быть либо тестировщики других команд, которые уже закончили релизное тестирование, либо разработчики команды, либо сам QA-координатор).

И конечно, ни один релиз не обходится без возникающих проблем. Мы их решаем и разрабатываем план, как избежать их в дальнейшем. Вот некоторые, с которыми мы сталкивались в последнее время:

• Проблема: иногда команды добавляют свои изменения в релиз в последний момент перед началом стабилизации, из-за этого стабилизация начинается позже, и обычно такие изменения содержат баги, потому что из-за спешки их могли не очень тщательно протестировать в спринте.
  Решение: стараемся избегать добавления таких опасных изменений.
• Проблема: баги находятся на этапе тестирования конфигурации на pre-production окружении. Это слишком поздно приходится исправлять и пересобирать релизный пакет.
  Решение: после таких ситуаций мы обновляем критичные области на стабилизации.
• Проблема: увеличение времени на тестирование релиза, что может быть причиной сдвига даты релиза.
  Причинами увеличения времени могут быть следующие факторы:
  a) сдвиг релиза в целом по каким-то веским причинам и тем самым больший объем командных изменений в релизе (время между релизами не месяц, а несколько месяцев),
  b) нестабильная работа окружения для тестирования стабилизации или конфигурации,
  c) конфигурационные баги окружения,
  d) большое количество нетривиальных багов команды, найденных на стабилизации. Как правило, это интеграционные баги, связанные с изменением одной области разными командами.
  Решение: в таких случаях мы стараемся успеть протестировать всё необходимое для релиза, даже если это требует участия в релизе все 2 недели или сверхурочную работу, так как релиз является более приоритетной задачей, чем задачи спринта.

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

Работа в условиях карантина: как обеспечить работу тестировщиков

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

В период пандемии, когда и Норвегия, и Россия отправили большинство населения на самоизоляцию, нам пришлось перейти на удаленную работу.

Мы продолжили работать в обычном режиме: команды всё так же заканчивали спринты с хорошими показателями продуктивности спринта, а релизы выпускались в назначенные сроки.

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

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

Единственная проблема, с которой мы столкнулись, сидя дома на удаленной работе в силу особенностей VPN невозможно было тестировать систему на командном окружении с телефонов/планшетов. Но эту проблему удалось обойти спасибо менеджеру проекта и IT-службе, которые нашли решение. Мы стали использовать прокси при подключении по домашней сети, и теперь можем тестировать на мобильных устройствах из дома.

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

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

Заключение

Подводя итог вышесказанному, хочется отметить несколько моментов:

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

20 октября 2020 года DINS проведет онлайн-конференцию для QA-инженеров и разработчиков. Мы хотим объединить инженеров из разных городов России, чтобы вместе обсудить боли, интересные кейсы, проблемы, любимые (и не очень) технологии. Ведущим конференции и модератором круглого стола станет Артем Ерошенко.

Участие бесплатное, но нужно зарегистрироваться.

Под катом программа, спикеры и другие подробности о конференции.

Программа

Топ-10 вредных советов и к чему они могут привести (Ирина Ушакова, EPAM, Нижний Новгород)

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

Ирина Ушакова Senior QA Engineer в EPAM. В IT-сфере более 8 лет. Начинала в качестве аналитика и переквалифицировалась в QA-инженера. Выступала на QA Z-Days 2020.

Автоматизация тестирования мобильного приложения Яндекс.Деньги (Александр Наташкин, Яндекс.Деньги, Санкт-Петербург)

Алекандр поделится кейсом Яндекс.Денег по автоматизации тестирования мобильного приложения. Он расскажет, какие подходы и инструменты сработали, а какие не очень, и как менялись технические потребности с ростом команды.
Поговорим об автотестах, разработке фреймворков и настройке CI, увидим метрики до/после внедрения автоматизации.

Александр Наташкин руководитель мобильного тестирования, Яндекс.Деньги. За 7 лет в QA прошел путь от ручного тестировщика до руководителя. Преподает в учебном центре Otus.

Отлавливаем баги в коде и рабочем процессе (Елена Гурова, Usetech, Ростов-на-Дону)

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

Звездами шоу будут:

• А давайте релиз в пятницу, во второй половине дня?
• Как это попало в продакшн?!
• Вы же уже исправляли это, почему опять сломано?

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

Елена Гурова Team Lead QA в Usetech. Елена в тестирование попала случайно, фактически, убегая от саппорта, но оказалось, что эта область самая родная и любимая. Преподает в корпоративном университете компании, читает лекции в GeekBrains и выступает на профильных мероприятиях (#RndTech).

Качество релизов ответственность команды (Людмила Малеева, Miro, Пермь)

Людмила расскажет про процессы тестирования и релизов в Miro: как они взаимосвязаны и как в компании повышают качество релизов. Вы узнаете, с помощью каких инструментов построить процессы, чтобы релизить с большим количеством команд и монорепозиторием.

Людмила Малеева QA engineer в Miro. Работала с автотестами, ручным и нагрузочным тестированием, построением процессов и релизами. Последний год занимает роль Release Manager. Выступала на локальных митапах Xsolla и СКБ Контур.

Круглый стол с программным комитетом QA Meeting Point

Инженеры из DINS обсудят одну из этих тем:

• Правда или миф: хороший QA-инженер не будет оставаться в профессии, а станет разработчиком
• Не надо так: деплоймент на продакшн по пятницам и тестирование на прод
• Стоит ли ломать продакшн для проверки высокой доступности и безопасности

Прими участие в выборе темы в Telegram-канале конференции с 9 октября до 14 октября.

Регистрация

Участие в конференции бесплатное, но нужна предварительная регистрация, чтобы в день мероприятия мы прислали ссылку на онлайн-трансляцию.

Всу участники первыми получат записи докладов с QA Meeting Point.

В этом месяце случилось сразу два приятных сюрприза. Первый релиз ядра Linux Kernel 5.8. Второй выход офисного пакета LibreOffice 7.0. Уже готовы пакеты для разных ОС, включая Linux, Windows, MacOS.

В седьмой версии офисного пакета много изменений. 74% добавлены сотрудниками организаций вроде Collabora, Red Hat и CIB, все остальное результаты труда независимых разработчиков.

Что нового?

Главные изменения

Седьмая версия пакета получила поддержку формата OpenDocument 1.3 (ODF), а значит, возможность защиты документов при помощи цифровой подписи и шифрования контента ключами OpenPGP. Добавлен отдельный тип верхних и нижних колонтитулов для главной страницы, улучшено отслеживание изменений в документе.

Благодаря 2D-библиотеке Skia расширены возможности отрисовки текста, кривых и изображений. Правда, по умолчанию он включен только для Windows.

Значительно улучшена совместимость пакета с форматами вроде DOCX, XLSX и PPTX. Теперь документы можно сохранять в режиме MS Office 2013/2016/2019. Ликвидирована проблема, которая приводила к ошибке invalid content error при открытии экспортированных файлов XLSX с формами.

Плагины kf5 (KDE 5) и Qt5 получили поддержку экранов с высокой плотностью пикселей.

При новой установке заблокирована панель, так что теперь ее нельзя случайно удалить.

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



Разработана новая тема пиктограмм Sukapura, которая полностью соответствует рекомендациям оформления macOS. Для этой ОС тема включена по дефолту.


^{Источник: documentfoundation.org}

Обновлена и тема пиктограмм Colibre, которая используется в Windows. Она соответствует стилю MS Office 365.



Установщик для Windows получил новые пиктограммы и визуальный стиль.



Теперь у Writer в номерах страниц и нумерованных списках можно оперировать выровненными числами. Там, где нужно, редактор добавит нули в нужном количестве.



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

В Calc добавлены новые функции RAND.NV() и RANDBETWEEN.NV(). Они генерируют результат единожды, не пересчитывая его при изменении ячейки.

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

Шаблоны lmpress переведены на формат соотношения сторон 16:9 вместо 4:3.



Для людей с проблемами со зрением добавлен специальный инструмент, который позволяет настраивать отображение текста под себя.



Для русского и украинского языков добавлена автозамена ASCII-кавычек с апострофом (), указанных вместо закрывающейся кавычки ().

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

Добавлена поддержка модулей Java. Сейчас доступно два модуля org.libreoffice.uno и org.libreoffice.unoloader. Файлы juh.jar, jurt.jar, ridl.jar и unoil.jar объединены в один архив libreoffice.jar.

И еще одно важное обновление: для выполнения скриптов теперь нужен Python 3, поддержка Python 2.7 удалена. Убран и фильтр экспорта в Adobe Flash.

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

Новая версия, несмотря на то, что она еще не вышла, считается релизом с максимальным количеством изменений за всю историю Linux. В коде релиза появилось свыше 1 млн новых строк. Скорее всего, оценить новинку можно будет в ближайшие пару недель Линус Торвальдс выпустит RC1, если не произойдет ничего экстраординарного.

А пока обсудим список изменений.

Так, новое ядро оптимизировано под работу с новейшими процессорами от Intel и AMD, рядом других чипов и модулей, архитектурой ARM. Добавлены сетевые компоненты, появились новые open source драйверы графики AMD Radeon. Кстати, стабильная версия этой ветки ожидается примерно к концу лета началу осени. Именно тогда должны появиться Ubuntu 20.10 и Fedora 33 с поддержкой нового ядра.

В новом ядре есть возможность конфигурировать флеш-массивы на базе MLC в качестве SLC. Развитие получил драйвер Microsoft exFAT, оптимизированы SMB3, EXT4 и Btrfs. Также добавлена поддержка DAX для прямого доступа к энергонезависимой памяти.


Источник

Кроме того, команда Linux добавила следующие нововведения:

• Поддержка шифрования с использованием Trusted Memory Zones на GPU AMD;
• Поддержка буферов обмена P2P/DMA между графическими ускорителями (в частности, для свежих AMD);
• Обновления драйверов AMD, NVIDIA и Intel (включая начальную поддержку Gen12), а также Habana Gaudi;
• Драйвер AMD Energy наконец-то откроет для доступа сенсоры Zen/Zen 2;
• Появится поддержка живой миграции с KVM для процессоров AMD;
• Драйвер CPUFreq получит поддержку boost;
• Появится поддержка PCIe NTB для Intel Ice Lake Xeon;
• Реализована начальная поддержка архитектуры POWER10;
• Уже ставшие традиционными патчи против side-channel уязвимостей для основных архитектур и их оптимизации.

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

Известно, что примерно 40% изменений в новом ядре связано с драйверами, 16% с обновлением кода для различных процессорных архитектур, 10% изменений связаны с сетевым стеком, 3% с файловыми системами.

Общее количество новшеств превысило 14 000, и они затронули примерно 20% файлов в репозитории. Размер патча 5.8-rc1 61 МБ.

А вы ждете новый релиз Linux? Пишите, что думаете об изменениях, в комментариях!

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

Explore

Практически все Chromebook поставляются со встроенным хелпом, Get Help. Благодаря ему пользователи знают, где что находится и как воспользоваться необходимой функцией.

Недавно разработчики Chrome OS заявили, что Get Help проходит ребрендинг и вскоре будет представлена полностью обновленная версия. Так и получилось. Get Help обновилось, и эта новая версия стала частью Chrome OS 84. Правда, теперь приложение называется Explore. Основная особенность работа в оффлайн-режиме.

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

Обзорный режим

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

Микрофон

В окружение для запуска Linux-приложений, Crostini, добавлен доступ к микрофону. Получить его можно с помощью раздела настроек Linux (бета). По умолчанию доступ к микрофону запрещен, что выглядит вполне логичным шагом.

Экранная клавиатура

Размеры экранной клавиатуры теперь можно менять (наконец-то). Для этого нужно перемещать любой из ее краев.

Захват видео в MP4

Пользователи хромбуков знают, что видео, захватываемое камерой устройства, всегда сохранялось в формате .mkv. С этим все ок, если вам эти видео нужны для просмотра на своем же устройстве или отправки коллеге с Chromebook. Но на многих других устройствах .mkv не всегда воспроизводится корректно. Поэтому разработчики Chrome OS упростили всем жизнь и добавили возможность сохранения записанного видео в формате .mp4.

И кое-что еще

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

• Использование кнопок управления громкостью для создания фотоснимков при помощи встроенной камеры или управления записью видео, если устройство находится в планшетном режиме. Экранный ридер ChromeVox теперь поддерживает поддержку поиска по командам, параметрам и режимам.
• Ликвидация 208 багов в Chrome OS.
• Блокирование загрузки по незащищенному соединению исполняемых файлов.
• Парочка новых эмодзи.

С момента выхода прошлой версии nginx прошел целый год. Сейчас представлена новая стабильная ветка nginx 1.20.0. По словам разработчиков, в нее вошли все изменения, которые ранее были накоплены в ветке 1.19.x. В новой ветке изменения будут связаны с ликвидацией серьезных ошибок и уязвимостей.

В ближайшее время разработчики сформируют основную ветку 1.21, которая будет получать новые возможности. Тем пользователям, кому не нужна совместимость со сторонними модулями, рекомендуется использовать основную ветку. На ее основе раз в квартал формируются выпуски коммерческого продукта Nginx Plus.

Немного статистики

Согласно данным компании Netcraft, nginx используется на 20,15% всех активных сайтов. Год назад этот показатель составлял 19,56%, два года назад 20,73%. Nginx находится на втором месте после Apache, доля которого составляет 25,38% (год назад 27,64%). На третьем месте находится Google с 10,09%, а на четвертом Cloudflare (8,51%).

Если учитывать все сайты, то nginx является лидером с 35,34% рынка. У Apache 25,98%, у OpenResty (платформа на базе nginx и LuaJIT.) 6.55%, Microsoft IIS 5.96%.

Если же оценивать использование nginx самыми посещаемыми сайтами в мире, то доля nginx составляет 25,55% (год назад 25,54%, два года назад 26,22%). Количество сайтов, которые работают под управлением nginx, составляет 419 млн. В России nginx используется на 79,1% самых посещаемых сайтов (год назад 78,9%).

Ну а теперь об изменениях

Новый релиз получил сразу несколько заметных улучшений:

• Возможность проверки клиентских сертификатов с привлечением внешних служб на базе протокола OCSP (Online Certificate Status Protocol). Для включения проверки предложена директива ssl_ocsp, для настройки размера кэша ssl_ocsp_cache, для переопределения URL OCSP-обработчика, указанного в сертификате, ssl_ocsp_responder.
• В состав новой версии вошел модуль ngx_stream_set_module, позволяющий присвоить значение переменной:

    server {        listen 12345;        set    $true 1;    }

• Разработчики добавили директиву proxy_cookie_flags для указания флагов для Cookie в проксируемых соединениях.
• Добавлены и директивы ssl_conf_command, proxy_ssl_conf_command, grpc_ssl_conf_command и uwsgi_ssl_conf_command, при помощи которых можно задать произвольные параметры для настройки OpenSSL. Так, при необходимости приоритизировать шифры ChaCha и выполнить расширенную настройку шифров TLSv1.3 можно указать:

   ssl_conf_command Options PrioritizeChaCha;   ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;

• Еще одно важное обновление добавление директивы ssl_reject_handshake, которая предписывает отвергать все попытки согласования SSL-соединений (например, можно использовать для отклонения всех обращений с неизвестными именами хостов в поле SNI).

   server {        listen 443 ssl;        ssl_reject_handshake on;    }     server {        listen 443 ssl;        server_name example.com;        ssl_certificate example.com.crt;        ssl_certificate_key example.com.key;    }

• В почтовый прокси вошла директива proxy_smtp_auth, которая дает возможность аутентифицировать пользователя на бэкенде при помощи команды AUTH и механизма PLAIN SASL.
• Добавлена директива keepalive_time. Ее задача ограничение общего времени жизни каждого keep-alive соединения, по истечении которого соединение будет закрыто (не путать с директивой keepalive_timeout, определяющей время неактивности, после которого keep-alive соединение закрывается).
• Появилась переменная $connection_time, через которую можно получить информацию о продолжительности соединения в секундах с миллисекундной точностью.
• В уже имеющиеся директивы proxy_cache_path, fastcgi_cache_path, scgi_cache_path и uwsgi_cache_path добавлен параметр min_free, регулирующий размер кэша на основе определения минимального размера свободного дискового пространства.
• Директивы lingering_close, lingering_time и lingering_timeout адаптированы для работы с HTTP/2.
• Разработчики также приблизили код обработки соединений в HTTP/2 к реализации HTTP/1.x. Поддержка отдельных настроек http2_recv_timeout, http2_idle_timeout и http2_max_requests прекращена в пользу общих директив keepalive_timeout и keepalive_requests. Удалены настройки http2_max_field_size и http2_max_header_size, вместо них нужно использовать large_client_header_buffers.
• Появилась новая опция командной строки "-e". Она дает возможность указать альтернативный файл для записи лога ошибок, который будет использоваться вместо лога, заданного в настройках. Вместо имени файла можно указать специальное значение stderr.