...

суббота, 23 января 2021 г.

Tachyum открыл предзаказ на эмуляторы 128-ядерных CPU Prodigy

Словацкий стартап открыл предзаказ на эмуляторы новых процессоров — как программных, так и на FPGA — и показал рабочий UEFI.

На конференции ISC 2020 молодой стартап из Словакии Tachyum представил процессоры собственной разработки Prodigy и ИИ-комплекс на их основе. Предполагается, что эти CPU будут использоваться в суперкомпьютерах, системах Big Data и ML.

Разработчики громко заявляют, что новый чип готов «ударить» по флагманам рынка — Intel Xeon и AMD EPYC. Производится процессор будет по нормам 7-нм техпроцесса на мощностях тайваньского TSMC. На борту Prodigy ожидается до 128 ядер частотой 4 ГГц, 12-канальный контроллер DDR5 с поддержкой до 512 гигабайт на каждый канал, 48 линий PCIe 5.0 и два контроллера Ethernet 400G. В линейке также есть и варианты «послабее» — с 16, 32 и 64 ядрами на выбор.

Как заявляют представители компании, производительность Prodigy на классических вычислениях FP32/FP64 будет достигать 16 и 8 Тфлопс соответственно. Однако в задачах ML и инференса цифры совсем другие — 262 Тфлопс.

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

В середине декабря прошлого года компания анонсировала старт предзаказов на «железный» эмулятор. По заявлениям представителей, поставлять его начнут уже в первом квартале наступившего 2021-го. Кроме того, ранним последователям доступно и программное решение, отличающееся более низкой стоимостью.

Поставки эмуляторов позволят начать разрабатывать ПО под новый чип, однако некоторые наработки уже есть. Также в декабре создатели заявили, что OEM и ODM-партнеры компании получат UEFI для новой архитектуры — как в бинарном виде, так и исходные коды. 

Кроме UEFI уже разработано и ядро Linux, поддерживающее новою архитектуру, средства разработки (включая компиляторы для AI-задач) и отладчики кода. На Prodigy также успешно запустили бинарный код, разработанный под архитектуры x86, ARM и RISC-V. 

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

Let's block ads! (Why?)

Компания T-Head собрала порт Android 10 для процессоров архитектуры RISC-V

Китайская компания T-Head, входящая в состав Alibaba Group, представила результаты своей работы по портированию свободной версии Android на платы архитектуры RISC-V. Команда проекта успешно запустила порт AOSP (Android Open Source Project) на плате ICE EVB. Сама плата оснащена тремя ядрами XuanTie C910 1,2 GHz (RISC-V 64) и ядром XuanTie C910V для векторных вычислений и GPU с поддержкой аппаратного ускорения и декодирования HEVC, AVC и JPEG.

Зачем нужно было портировать Android на весьма маломощную плату? В первую очередь — возможность свободного использования в любых целях. AOSP не подпадает под ограничения авторских прав. При этом сама платформа RISC-V предлагает инженерам открытую и достаточно гибкую систему инструкций для самого широкого применения. Запуск же Android 10 на процессорах RISC-V — это отличная новость для сегмента интернета вещей. Именно в этой области T-Head планирует развивать свою разработку, включая системы умного дома, датчики и умную технику.

Использование же маломощных плат RISC-V в связке с такой программной платформой, как Android, значительно упрощает производство и написание программного обеспечения для "умных" устройств. Из более привычных устройств новинка может быть применена в телевизорах, планшетах и даже смартфонах.

Важно отметить, что используемый в демонстрации XuanTie C910 — далеко не новинка в мире микроэлектроники. Alibaba представила данный чип публике еще в 2018 году и уже тогда компания говорила о преимуществах свободы архитектуры RISC-V. Тогда же прогнозировалось применение XuanTie C910 и других чипов компании в сфере интернета вещей.

Возможно, это только первый релиз подобного рода. В ноябре 2020 года T-Head совместно с Allwinner показали один из самых дешевых чипов на рынке — одноядерный XuanTie C906 за 12,50$ и проект платы на его базе. Сама плата, которая планируется к производству по итоговой цене около 26$, будет работать под управление Debian.

Рендер модуля Allwinner на основе чипа XuanTie C906
Рендер модуля Allwinner на основе чипа XuanTie C906

RISC-V уже широко поддерживается различными компаниями и проектами. Сейчас на базе спецификации RISC-V под различными свободными лицензиями (BSD, MIT, Apache 2.0) развивается несколько десятков вариантов ядер, около сотни SoC и уже производимых чипов. Поддержка RISC-V присутствует, начиная с выпусков Glibc 2.27, binutils 2.30, gcc 7 и ядра Linux 4.15.

Вполне вероятно, что работа, проделанная инженерами T-Head по портированию Andriod, даст этим проектам дополнительный импульс и откроет новые пути развития. Вся информация и патчи доступны на GitHub.

Let's block ads! (Why?)

Я сделаю свою «умную» колонку… «with blackjack and hookers!»

Привет всем. В данной статье я расскажу историю как мы с двоюродным братом сделали свою «умную» колонку.

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

За мной сама идея, программирование, железо (подбор и настройка).

От брата 3D-модель, 3D-печать, железо (подбор и электромонтаж).

Статья по-большей части описывает то, что делал я, лишь немного касаясь 3D-модели.

"Ты на самом деле хочешь дружить с роботом?"

Будучи большим фанатом известного мультсериала «Футурама», однажды (где-то в 2018 году) мне захотелось заиметь самодельную голову робота Бендера Родригеса. В голове, в том числе крутились дурацкие варианты сделать её из какой-нибудь кастрюли. В силу своей глупости идея была забыта и заброшена ровно до того момента пока у одного хорошего человека, моего брата, товарища xbost’а не появился 3D-принтер (весна 2019 года). И тут эта идея снова ожила…

Обсудив эту идею за пивом, принялись за работу. Брат начал делать 3D-модель, а я искать, что из электронного хлама в ящике стола можно задействовать в проекте.

К тому моменту, у меня уже несколько лет валялась без дела плата Intel Galileo Gen2. И было желание задействовать её в этом проекте. Изначально никаких «умных» функций не планировалась, просто запихнуть её в корпус вместе с динамиком и светодиодами, вытащить кнопочку, при нажатии на которую воспроизводились бы цитаты из серий и светились диоды.

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

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

Первые попытки

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

В силу своей природной… хм… невнимательности, я упустил существование более подходящей для моей задачи версии – pocketsphinx, и начал с «большого» CMU Sphinx на Java.

Создал простенькие JSGF-грамматику и программу на Яве. Взял несколько наиболее известных цитат для проигрывания(“with blackjack and hookers”, “bite my shiny metal ass”, “kill all humans” и т.п.). Пробовал изначально на достаточно мощном компьютере(MacBook Pro 13-го года), был доволен результатом производительности, но понимал, что на Галилео меня ждёт нечто другое. Но дело оказалось совсем плохо.

Вообще Галилео уже давно заброшен Интелом. Стандартный Линукс, шедший с ним мне в принципе особенно не нравился. Поэтому попробовал с последней доступной для него сборкой Дебиан.

Туда с проблемами(подробности уже честно не вспомню) был поставлен JRE. В качестве устройства ввода/вывода аудио была использована USB-гарнитура. И… Результат был крайне печален в плане производительности. Сейчас опять же не вспомню, возможно неправильную акустическую модель использовал на ней, но на реакции уходило 30-60 секунд. Плюс брат начал разрабатывать 3D-модель, и сказал, что габариты Галилео большеваты. Плюс отсутствие встроенного Wi-Fi. В общем Галилео опять отправилась в стол.

Решено было попробовать на гораздо более популярной Малинке, и выбор пал на слабую, но самую компактную версию Raspberry Pi Zero W. А также, прокачав внимательность, узнал о pocketsphinx (отличная статья для старта), перешёл на него, и переписал программу на Питоне.

При переходе на Малину, с подачи xbost’а, родилось название для проекта – Pinder (Raspberry Pi + Bender). Да, я прекрасно помню историю с Pidora в русскоязычном сегменте, но в данном случае намеренно выбрал такое лулзовое для русского уха название.

И так предыстория завершена, можно переходить непосредственно к описанию Пиндера.

Внутренняя железная часть

Перечень использованных компонентов:

  • Raspberry Pi Zero W – собственно основа всего.

  • UPS-Lite for Raspberry Pi Zero

    Маленький ИБП для Малинки. Его штатный выключатель был выпаян, и к его контактам был припаян микропереключатель (см. далее по списку).

  • RGB адресная светодиодная лента на WS2812B, 60 светодиодов на 1 метр

    Для подсветки и анимации «зубов»(18 штук) и глаз(2 штуки).

  • USB-аудиокарта

    В принципе подойдёт любая, работающая в Линуксе. Подключается через OTG-кабель в единственный доступный для этого порт на Малине Зеро.

  • Усилитель и один динамик от таких колонок

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

  • Микрофон HBC10A

    Но во время разработки поначалу использовался микрофон от телефонной гарнитуры Philips.

  • Микропереключатель с лапкой KLS7-KW10

    Замыкается/размыкается при вставлении/вынимании "антенны" Бендера. Включает/выключает питание от UPS к Малине.

  • 3,5мм разъём и гнездо jack. Для подключения микрофона к аудиокарте (микрофон находится наверху Бендера, в антенне).

В общем внутри всё достаточно колхозно.

Схема подключений очень простая:

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

3D-модель, корпус

Здесь я не смогу рассказать многого, так как эта часть работы полностью брата.

3D-модель и небольшая инструкция доступны здесь.

Зубы и глаза напечатаны фотополимерной смолой на Anycubic Photon. Все остальные части PLA на Creality Ender 3.

Если будут какие-то вопросы по 3D-модели и печати можно задать мне, я их передам, либо попробовать напрямую спросить у xbost’а на thingiverse (но не уверен будет ли он на них отвечать).

Краткая схема сборки:

Фото

Фото в процессе сборки и полностью собранном виде:

Программная часть 1

В качестве ОС используется штатный Raspbian (теперь Raspberry Pi OS).

За распознавание, как уже писалось выше, отвечает pocketsphinx. В качестве аудиоподсистемы используется Alsa (Pulseaudio выпилен).

Подсветка управляется с помощью библиотеки Adafruit_Blinka.

Данные о заряде/напряжении читаются из UPS-Lite посредством SMBus.

При разработке никакими лучшими практиками не руководствовался, поэтому код «попахивает».

Код лежит здесь.

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

Основной целью была просто возможность отвечать фановыми фразами из серий. Задаешь ему вопросы типа “Как дела?”, “Где ты родился?”, “Что думаешь о Сири?”. Ищется и воспроизводится ответ из сэмплов (в случае отсутствия сэмпла используется синтез речи, но об этом чуть позже).

Изначально скорость ответов на Малине была не очень шустрой (4-6 секунд до ответа):

Покопавшись у себя в коде, были найдены и уничтожены необязательные паузы. То же самое касалось и сэмплов (были пустые места вплоть до 1 секунды в начале файлов).  А также прочитана информация о параметрах оптимизации pocketsphinx. Получилось уже получше:

Далее начал добавлять кое-какие полезные функции. Первой стала проигрывание музыки с локальной ФС или интернет-радио с помощью MPD. При этом докричаться до Бендера при проигрывании музыки на приличной громкости сложновато:

После достаточно долгого перерыва, живя на даче, была добавлена первая функция “умного дома”-  управление освещением в своём углу через ModBusTCP. Вот только Бендера недостаточно иногда просто попросить включить свет, нужно обязательно сказать "пожалуйста". Работает достаточно шустро:

Программная часть 2

Потом однажды захотелось добавить читалку RSS-новостей. Это уже было невозможно без синтеза речи, но при этом хотелось, чтобы синтезатор звучал как, или хотя бы похоже на голос Бендера. Такой синтез речи на Малине Зеро представляется малореальным и поэтому в этом моменте пришлось сдаться и задействовать онлайн-сервис.

Почитав информацию и попробовав разные варианты остановился на Microsoft Azure Custom Speech.

При создании пользовательского голоса на выбор есть три варианта:

  • Statistical Parametric – стандартное качество, нужно небольшое количество(для английского языка) сэмплов для обучения.

  • Concatenative – высокое качество, нужно 6000 сэмплов для обучения.

  • Neural премиум-качество. По факту недоступно(доступно из США, при написании челобитной в Майкрософт зачем тебе это нужно и выкладывании 100 000$).

Более подробно по технологиям синтеза речи можно почитать например на Википедии.

У меня не было большого количества сэмплов, поэтому сначала поигрался со Statistical Parametric. Результат был неплох, голос конечно не был похож(такой тип синтеза для сильной похожести и не предназначен), но интонации передавал сносно. В итоге на основе набора данных созданного с помощью этой модели я создал оффлайновую модель для CMU Flite, используемую в случае отсутствия связи с MS Azure.

Но всё же хотелось большей похожести и я решился попробовать собрать 6000 сэмплов для Concatenative модели, использующей отрывки из сэмплов настоящего голоса. Очень помог некий хороший человек, выложивший на YouTube 7 видео The Best of Bender. Надёргав оттуда сэмплов, приплюсовав к ним те что уже были и натравив на них майкрософтовский же Text-to-Speech (здесь у меня набор тулзов вспомогательных), получил что-то около 2000 транскрибированных сэмплов. Было принято решение просто скопировать это всё три раза под разными именами, чтобы получить 6000.

В итоге всё это было залито на обучение модели, и результат получился следующим:

Да конечно не идеально, но меня результат трудов устроил.

В итоге синтез речи используется не только для чтения новостей, но и в случае отсутствия оригинального сэмпла. Сначала ищется сэмпл. Если его нет, проверяется связь с порталом MS Azure, если есть – синтезируется с помощью него. Если же связи с Azure нет – используется локальная модель Flite(а для русского языка роботизированный голос eSpeak).

В сумме периодическими волнами и рывками разработка шла с весны 2019-го по весну 2020-го, в свободное время(хорошо видно по коммитам на гитхабе). Далее уже даже не волнами, просто отдельными всплесками.

Будущее

Как таковых планов развития проекта нет. Если появляется желание и вдохновение, то добавляю что-нибудь. Так конечно напрашивается сделать режим просто болталки на нейронке, обученной на фразах Бендера. Ещё возможно добавить режим bluetooth-колонки(и чтобы зубы загорались синим в этом режиме) и приложение для смартфона, для активации схемы патриотизма.

Но для начала надо изобрести удлинитель пальца.

Заключение

Исходный код ПО и 3D-модель выложены под открытыми лицензиями, так что если у кого-то есть желание сделать своего Бендера, добавить свои функции и улучшить – буду рад.

На этом статья подошла к концу. Спасибо, что прочитали!

Всем хороших новостей!

Let's block ads! (Why?)

Ушел из жизни один из создателей Objective C Брэд Кокс

Брэд Кокс, доктор философии из Манассаса, штат Вирджиния, скончался 2 января. Кокс известен тем, что участвовал в создании языка программирования Objective-C вместе с Томом Лавом.

Исследователь родился 2 мая 1944 года в Форт-Беннинге, штат Джорджия. Он с детства интересовался наукой. После окончания средней школы Лейк-Сити Кокс получил степень бакалавра наук в области органической химии и математики в Университете Фурмана и докторскую степень по направлению математической биологии в Чикагском университете.

Ученый устроился на работу в International Telephone and Telegraph (ITT), а затем присоединился к Schlumbeger-Doll Research Labs и в конечном итоге основал свой стартап Stepstone в Коннектикуте.

Кокс написал программу PDP-8 для моделирования кластеров нейронов. Он также работал в Национальном институте здравоохранения и Океанографическом институте Вудс-Холла.

Доктор Кокс в рамках Stepstone вместе с Томом Лавом выпустил первую реализацию Objective-C. Стив Джобс лицензировал язык Objective-C для использования в своей новой операционной системе NEXTSTEP. В конце концов его NeXT приобрела Objective-C у Stepstone. Язык продолжал оставаться основным для Apple OS X и iOS.

В 1991 году доктор Кокс выпустил свою книгу «Объектно-ориентированное программирование: эволюционный подход», а в 1996 году опубликовал еще один труд «Суперраспределение: объекты как собственность на электронных границах», который был переведен на 10 языков.

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

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

Let's block ads! (Why?)

Вакцины COVID, их сравнение и принципы действия

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

Вот некоторые научно-популярные статьи, которые могут служить как ликбез и более развёрнутое изложение:

Spoiler

Зачем ?

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

Учитывая, что цифры эффективности у всех высокие, но при этом разработку никто не бросает. Хотя для бизнеса (в т.ч. фармацевтического) ранняя остановка это распространённая стратегия, учитывая, что каждый следующий этап клинических испытаний намного дороже предыдущего.

Какие параметры вакцин важны ?

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

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

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

Конкретно в случае COVID этот параметр очень важен, так как в основном люди погибают не от поражения самим вирусом, а от friendly-fire собственного иммунитета, аутоимунной реакции. И вакцина, гипотетически, может усугубить ситуацию, при сочетании определённых неблагоприятных факторов. Но это очень активно отрицается. Задачей статьи не ставится сражение против (или за) теорий заговора, поэтому идём дальше : )

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

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

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

Какие вакцины бывают ? (противовирусные)

Живая

Состоит из ослабленных возбудителей заболевания. Ослабляют, как правило, воздействием радиации и/или химических агентов, обычно сильных мутагенов. Вирус остается "живой", т.е. способен к внедрению в клетку, но не способен размножаться (по крайней мере эффективно)

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

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

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

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

Доступность: Минимальная
Массовая культивация вирусов это сложный процесс, а когда вирус смертельно опасен для человека - вся техническая линия должна быть оборудована по уровню FP-3 или даже FP-4 лаборатории, что очень дорого, а развернуть быстро такие мощности просто невозможно. Живые патогены невероятно тяжело перевозить, невзирая на их уровень "ослабленности". Хранение при сверхнизких (< 70 C) температурах.

Дополнительно: исторически первый класс вакцин, в производстве и разработке не требует rocket science и прочих чудес молекулярной биологии.

Инактивированная

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

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

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

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

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

Доступность: низкая
Массовая культивация так же проблематична, как и для живой вакцины. Транспортировка ощутимо легче, но всё равно ограничен специальными регламентами. Может быть произведён вариант, при котором вакцина хранится при низких (~ -2-10 C) температурах.

Примеры: Sinovac (CN), Valneva (FR), вакцина центра Чумакова (RU)

Белковая

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

Имуногенность: средняя
Вакцина содержит только релевантные (по мнению исследователей) белки, обычно один белок. В случае COVID это, зачастую, белок "шипа", которым вирус связыватеся с клеткой. Капсид вирусов, вспомогательных белков, РНК материала нет, поэтому такая вакцина действует только на антиген-презентирующую систему.

Селективность: высокая
До всех клеток доходит один и тот же белок, с незначительными модификациями, идентичными натуральным (встречающихся в реальных вирусах). С т.з. data science это можно было бы назвать хорошим репрезентативным dataset (правда без контрпримеров).

Длительность: высокая
См. предыдущее описание, высокая селективность ~> высокая длительность.

Опасность для реципиента: низкая
Основной риск это высокоспецифичная аллергическая реакция, они очень редкие.

Доступность: средняя
Технические процессы культивации рекомбинантных белков сравнительно хорошо разработаны, после решения научных задач (введение гена, совместимость, обеспечение необходимой конформации, разработки методов экстракции) технология хорошо масштабируется. В то же время научная часть наиболее сложная (сравнимо с другими вакцинами). Хранение возможно при небольшом минусе, логистика сравнительно простая.

Примеры: Novavax (US), частично ЭпиВакКорона (RU)

Генетическая

Вносит в клетки организма генетический материал, необходимый для синтеза имуногенного белка вируса (в случае COVID это модифицированный белок шипа). Белок презентуется антиген-презентирующей системой и вызывает имунный отклик. Есть несколько подвидов, в зависимости от способа доставки генетического материала в клетку:

  • Векторный - целевой ген доставляется при помощи генетического вектора, обычно модифицированного безвредного вируса

  • мРНК - доставляется уже собранная матричная РНК, на основе которой синтезируется целевой белок.

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

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

Селективность: средняя
Вакцина, как правило, несёт на себе ген, кодирующий один белок, а не их вариацию (как было бы в белковом варианте). Более того, вариация в структуре не идентично натуральным вариациям данного белка, из-за пост-трансляционных модификаций.

Длительность: средняя
См. предыдущее описание, высокая селективность ~> высокая длительность.

Опасность для реципиента: средняя
Наиболее понятный риск это высокоспецифичная аллергическая реакция, они достаточно редкие. Тем не менее, такая вакцина уже является генной терапией (первой массово применяемой), а в целом, что происходит на таком "низком", молекулярно-биологическом уровне очень слабо изучено. Особенно в случаях со-заражения другим вирусом, который несёт на себе обратную транскриптазу. И какие будут последствия экспрессии изменённого белка через полную цепочку превращений (в зависимости от того, начал ли белок синтезироваться с транскрипции, или сразу с трансляции, список модификаций будет разным, из-за пост-транскрипционных модификаций).

Недавно стало известно, что COVID иногда может встраивать фрагменты своего кода в генетический материал человека, без применения обратной транскриптазы, как - непонятно. Как это может взаимодействовать с вакцинами - тоже. Хотя в многих научно-популярных статьях утверждается, что mRNA Vaccines Are Not Going To Affect Your DNA, но я бы назвал бы это очень смелым утверждением, учитывая уровень непонимания того, что происходит. Более того, по личному опыту я замечаю, чем более человек разбирается в молекулярной биологии, тем менее он уверен в том, как что-то работает и категоричен в утверждениях.

Доступность: высокая
Производство сравнительно просто, хорошо масштабируется и безопасно. В зависимости от технологии производства для хранения могут требоваться как и низкие (-70 C, в случае мРНК вакцины) так и обычные (-2-5 С, для векторных вакцин) температуры.

Примеры: Pfizer/NTech (GE+US), AstraZeneca (UK), Moderna (US)

Что не так с этим типом ?
Любая технология имеет плюсы и минусы. Взяв любой вопрос, даже не из медицины, например импульсные блоки питания, или использование крахмала в выпечке, или электромобили - всегда будут плюсы и минусы. В медицине так же - антибиотикотерапия, стероиды, гормоны - всегда есть за и против, в зависимости от ситуации. Но с применением генетических вакцин ситуация несколько иная, и в академических и в популярных статьях. Минусов просто нет. Во всяком случае автору статьи не удалось найти ничего серьёзного, только безусловные плюсы (с аккуратным замечанием, что это очень новый тип, и всякое может быть), ну и несколько мракобесов, тезисы которых опровергаются. Как минимум это подозрительно. Вместе с этим работает активная пропаганда среди населения и учёных, которая иногда вызывает обратный эффект.

Ажиотаж частично объясняется тем, что этот тип изучается более 40 лет, вложены большие деньги, но ни единой работающий, массово применяемой мРНК вакцины (не считая COVID) на данный момент нет. А гранты выделены, очень много статей написано, и естественно что исследователи защищают свои труды. Факт, что первое применение фундаментально нового типа вакцин совпадает с невероятной срочностью тоже не внушает автору доверия. Такой скептицизм разделяют и знакомые иммунологи, отлично знакомые и с расширенными отчётами испытаний и участвующие в принятии релевантных политических решений.

Сводная таблица

Тип

Имун.

Селек.

Длит.

Безопас.

Доступность

Живая

Макс.

Макс.

Макс.

Мин.

Мин.

Мёртвая

Выс.

Сред.

Сред.

Низ.

Низ.

Белковая

Сред.

Выс.

Выс.

Выс.

Сред.

Генетическая

Сред.

Сред.

Сред.

Сред.

Выс.

Типы вакцин расположены в хронологическом порядке. Легко заметить, что оптимизировался в основном параметр доступности. Основной задачей массовой вакцинации является не защита каждого человека от инфекции, а достиждение невозможности её неконтролируемого распространения. Для этого определённая часть населения (в зависимости от типа вируса 20-70%) населения должна иметь иммунитет.

А какие вакцины уже есть ?

Все допущенные до клинического применения (в СНГ, ЕС И США) вакцины принадлежат к последнему классу - генетических вакцин: Спутник V, AstraZeneca, Pfizer, Moderna и остальные. Хотя конечный эффект у всех одинаковый (синтез, презентация белка и активация специфического иммунитета), механизмы несколько отличны.

Структура у всех общая - целевой ген (везде одинаковый) + переносчик информации (вектор или уже синтезированная мРНК) + упаковка вируса (тоже разная).

Pfizer/NTech использует мРНК, инкапсулированную в липидные везикулы, которые защищают РНК (оно исключительно хрупкое и химически неустойчивое) до попадания в клетку.

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

Ситуациии win-win нет, высокую эффективность демонстрирует вакцина Pfizer, но при этом требует хранения при температура -70. AstraZeneca может хранится при +2-8 но по результатам клинических исследований имеет эффективность 70% (против 95% у Pfizer). Впрочем, впоследствии результаты были скорректированы, и сейчас превышают 90% для всех типов вакцин.

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

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

Выводы

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

Протоколы лечения мягко говоря неадекватны (и, естественно, ортогональны международному опыту), и наивно полагать, что с вакцинацией уж точно лучше. Вакцинироваться ли, какой вакциной, какие риски - решать каждому. Но решать лучше осведомлённо, и не ориентироваться на популярность/магическое число эффективности : )

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

Люди, имеющие бронхиальную астму, не относятся к группе риска. Даже наоборот, шанс заболеть (и тяжело заболеть) COVID'ом для них намного ниже, чем в среднем по популяции.

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

P.S.S. В статье намеренно опущено большинство механизмов и технических деталей, и касаемо производства вакцин, и функционирования иммунитета и многого другого, чтобы сохранять объемы адекватными. Если вам кажется, что какой-то вопрос слишком упрощен/упущено что-то важное - напишите в комментариях, я дополню статью.

Let's block ads! (Why?)

Интервью с Senior Android Developer Spotify Славой Савицким

Неделю назад у нас выступал Слава Савицкий — Senior Android Developer в Spotify. Слава рассказывал о том, как айтишники живут в Швеции (например, он брал декретный отпуск по уходу за ребенком), о работе в Spotify, о новом приложении Spotify Lite для слабых андроидов, и, конечно, об Андроид-разработке в целом.

Делимся с вами записью и расшифровкой эфира.


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

Я из города Саров Нижегородской области. Федеральный ядерный центр, 100 тысяч населения. Как ни странно, в Spotify есть еще один сотрудник из Сарова.

Я закончил мехмат МГУ в 2009 году, с 2006 работал в Институте системного программирования по контракту с компанией Klocwork, канадской; занимался статическим анализом для поиска дефектов. Статический анализ исходного кода – я, по сути, писал компиляторы, которые на выходе давали не объектный код, а сообщения о потенциальных ошибках.

В 2013 году я переехал в Швецию, в Стокгольм, работать в компании Blackberry. Это была моя первая работа с мобильными устройствами. Я писал для системы Blackberry X приложения для работы с мультимедиа – story maker, video editor. Потом я работал в компании Sinch, которая занималась VoIP, SDK для мобильных приложений. После этого работал в одном банке, переписывал социальное приложение для инвесторов. Последние 2.5 года я работаю в компании Spotify, тоже с мобильными приложениями.

Жизнь в Швеции: налоги, доверие к государству, анти-выгорание и офисы IT-компаний


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

Что все знают о Швеции? Фотографии с автобусных остановок, где все стоят на расстоянии 1 метр друг о друга и спокойно ждут автобуса. Страна для спокойных людей. Здесь редко что происходит, глобальных новостей, как в России, не бывает.

Еще все вспоминают высокий скандинавский уровень счастья и спокойствия; здесь все размеренно, спокойно, не очень много стрессов. Конечно, стресс себе найти можно: устроиться на работу, выгореть там… Большое внимание уделяется балансу семьи, работы, отпуска. Вполне нормально летом, когда хорошая погода, пойти купаться с работы в 15 часов. Приоритет сдвинут в сторону семьи.

Еще тут есть декрет для отцов; он необязателен, но, если эти дни не брать, то они сгорают. Декреты выдает государственная служба социального страхования на некоторое количество дней, которое делится между отцом и матерью, часть оплачивается по высокой ставке, а часть – по низкой. Ставка – до 80% зарплаты; с этого еще платятся налоги, и существует верхняя граница. Для Стокгольма 5 лет назад (тогда я ходил в декрет) это было 33 тысячи крон – то есть, не очень много. Для программистов это обычно меньше половины зарплаты, но, все же, существенная поддержка. Если бы я работал в Спотифае на тот момент, то Спотифай доплатил бы до 100% зарплаты. Причем Спотифай делает это не только в Швеции, но и в США, что вообще немыслимо.

Вам дают эти дни, вы можете не работать, когда у вас появляется ребенок; у вас две недели отпуска, чтобы с ним познакомиться. В общем, здесь очень спокойное отношение к тому, когда вы занимаетесь своей семьей, а не работой. Многие мигранты совершают эту ошибку: в первый день на работе сидят до 11 часов вечера, пытаясь в чем-то разобраться, а на следующий день к ним приходит менеджер, в ужасе: зачем? Почему ты так? Давай мы тебе поможем! Все сейчас сделаем, все объясним, не надо так работать!

Наверно, все слышали про понятие «лагом» — «ни много, ни мало, столько, сколько нужно». Это такой принцип шведской жизни, наряду с другим принципом, который, наверно, на все скандинавские страны распространяется: «хюгге» — это когда вы устраиваете себе спокойный отдых дома. То есть, вы находитесь дома, вы устраиваете себе ванну, вы хорошо покушали – в таком плане.

Не могу сказать, что здесь все интроверты, но для меня, как для интроверта, это прекрасная страна в плане темпа жизни. Конечно, это не для всех; здесь у власти очень много лет подряд были социал-демократы, и общество во многом построено на принципе уравнивания доходов. Это хорошо, если вы во время пандемии оказались низкооплачиваемым сотрудником – тогда государство вам будет доплачивать, и вы уже будете не таким низкооплачиваемым. Но для получения сверхдоходов это, конечно, плохо. Если вы хотите получать большие доходы в бизнесе, для этого Америка подходит больше.

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

Про погоду – сейчас зима, зимой в Швеции очень темно, очень долго. Зима не всегда снежная; в этом году снег выпал под Рождество. Не очень холодно, примерно -3. Так не всегда. Конечно, Швеция очень вытянута с юга на север, и на севере гораздо холоднее и снежнее, чем в стокгольмском регионе. Здесь бывают такие зимы, когда я хожу в осенней одежде. Сезоны выражены не очень, весна и осень обычно длятся по две недели. Все остальное – зима и длинное лето. Летом очень светло, не очень жарко, много вариантов выбраться на природу. Люди живут очень близко к природе; даже если вы работаете в офисе в центре Стокгольма, всегда рядом есть парк, есть вода. Я видел, как люди летом выходят из офиса и идут купаться, потом идут обратно в офис. Прямо во время обеденного перерыва.

Здесь есть такой закон – можно в любом месте, не обозначенном как частная территория (PRIVAT), поставить палатку. На любом поле; тут нет особенной охраняемой зоны около воды. Конечно, есть некоторые ограничения: надо находиться не ближе 100 метров от жилья, например, и за собой убирать, заботиться о природе. Но этот тип отдыха очень популярен, особенно в этом году, когда никуда особо не полететь.

Здесь очень высокое доверие к государству; это коррелирует с тем, что люди обычно чувствуют себя счастливыми. Государство во многом если и не заботится, то, по крайней мере, информирует вас о разных проблемах, возможностях борьбы с выгоранием, трудоустройства и так далее. То, как информировали о пандемии в Швеции, не сравнится с тем потоком противоречивой информации, который был в России.

Здесь было очень четко, здесь не было локдауна. Были свои проблемы, конечно; пандемия продолжается. Так как есть доверие к государству, многие просто выполняют государственные рекомендации – потому что попросили. Долгое время не было закона об экстренных полномочиях по поводу борьбы с пандемией; у парламента просто не было возможности издать какой-то закон, чтобы срочно закрыли все кафе. Были только рекомендации – «пожалуйста, не собирайтесь больше 6 человек». Запреты на собрания более 50 человек были, но не было такого, чтобы всех заставлять носить маски, например. И этот подход виден во многом. В пользовании природой, в подходе к пенсиям. У всего населения очень высокая финансовая грамотность, все вкладывают в пенсию, все инвестируют; у всех есть понимание того, в каком состоянии сейчас фондовый рынок, экономика, сколько они переплачивают за ипотеку. Все это на высоком уровне, и многое из этого разъясняется государством.

Здесь много IT-компаний с офисами по всему миру, многие из них были основаны в Швеции – хотя бы Ikea, Spotify. Может быть, кто-то слышал про Klarna – это компания, которая предоставляет электронные платежи. У них очень много хороших IT-практик, они несут информацию в массы, их часто можно увидеть в IT-блогах, технических дискуссиях и форумах. IT-шнику здесь довольно легко найти работу.

Налоги большие, хотя и не самые высокие в Европе; с зарплаты вы платите около 30%, но больше ничего не платите. Здесь довольно прозрачная система: можно посмотреть, почему именно 30% (это зависит от региона и даже района). Если компания с вами рассчитывается акциями, то за опционы вы можете заплатить в два раза больше: 30 за конвертацию опционов в акции и 30 подоходного налога.

Я никогда не замечал, чтобы все шведы были нелюдимыми, плохо шли на контакт и плохо дружили. У меня есть хорошие друзья, и шведы, и другие. Может быть, в IT люди более открытые.

О работе в Spotify


Spotify в этом году, в июле, запустился в России – была очень агрессивная маркетинговая кампания. Я в запуске принимал непосредственное участие, нажимал некоторые кнопки, делал тестирование Android-приложения.

Spotify – это стриминговая платформа, которая позволяет слушать аудио из Интернета, ничего не скачивая предварительно на телефон. В России это в основном музыка. По миру бывают также подкасты, аудиошоу, аудиокниги, театральные пьесы (как раньше было по радио). Миссия Spotify – «открыть креативный потенциал артистов, позволить миллионам артистов жить на доходы от их творчества, позволить миллиардам фанов слушать и быть вдохновленными артистами».

Spotify как компания занимает в Швеции первое место в рейтинге самых привлекательных работодателей. В прошлом году она обогнала Google; на третьем месте – Ikea.

Вопрос: как обстановка с мигрантами с Ближнего востока?


Очень много было мигрантов в 2014-15 годах, за счет беженцев из Сирии. Швеция объявила, что будет принимать достаточно много беженцев, больше, чем положено по квоте ЕС. Лично у меня было много проблем с продлением документов, потому что вся миграционная служба была занята обработкой документов приезжающих беженцев (в основном). Я ждал разрешения на продление моего пермита на работу (он у меня был, но, если бы я выехал из страны, то не смог бы вернуться из-за истекшего срока действия). В плане интеграции в общество – как везде; есть хорошие и плохие примеры, есть гетто и бандитизм. Но я думаю, что, в целом, у нас в этом плане не хуже, чем везде.

В команде Spotify Lite я – старший разработчик, занимаюсь Android-приложением. Я не product-менеджер, поэтому многие вещи, которые в Spotify происходят, для меня непонятны. Бывает так, что приглашают на интервью менеджера какого-нибудь большого продукта, и он рассказывает, что где происходит и что как работает, но я могу рассказывать только с точки зрения инженера. Как инженер, я знаю, что поменять, чтобы что-то заработало.

Старший разработчик – это тот, кто знает, что ответ на главный вопрос Вселенной – не «42», а «it depends». То есть, «все зависит…». И надо знать, от чего зависит, почему зависит, и как сделать так, чтобы работало.

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

Еще я – техлид команды; знаю, что где происходит, кого надо пнуть, чтобы что-то случилось в компании.

Про культуру и модель Spotify


Модель Spotify – это вот те видео пятилетней давности, которые есть в YouTube. Их делал специальный консультант, Henrik Kniberg – он создал эту модель, написал про нее книгу; у него еще несколько книг есть. Часто меня просят рассказать про эту самую модель Spotify, однако эта модель – уже дела давно минувших дней.

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

Есть и user insights – люди, которые отвечают за то, чтобы поговорить с настоящими пользователями перед тем, как начинать что-то делать, показать им какой-то предварительный продукт; фокус-группа выскажет свое мнение, и задача user insights – составить вопросы так, чтобы они дали какую-то информацию о том, что мы будем делать и как. Грубо говоря, какого цвета лучше делать кнопки. Конечно, это мы и без пользователя можем выяснить; вопросы задаются обычно более пространные.

Про культуру Spotify можно очень многое прочитать на портале рекрутинга Spotify. У нас есть некоторые ценности, «values», их 5.

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

  1. Innovative – инновация. Мы двигаемся быстро, принимаем риски, представляем новые идеи.
  2. Sincere – открытость, честность. У нас нет времени на внутреннюю политику.
  3. Passionate – мы целеустремленно занимаемся тем, что мы любим, мы верим в то, что мы делаем.
  4. Collaborative – мы работаем вместе, сообща, для достижения общей цели.
  5. Playful – мы не слишком серьезно к себе относимся, мы имеем возможность и смеяться на работе, и прикалываться, и получать поддержку от коллег.

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

Вопрос: почему от модели Spotify отказались?


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

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

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

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

Когда вам нужно сделать изменение в системе, вы его описываете в документе RFC (request for comment) и посылаете заинтересованным командам, в том числе вашей локальной группе, которая потом тоже показывает RFC заинтересованным людям. Вы собираете комментарии на ваш документ: что за изменение, кого оно затронет, кто должен это делать, надо ли это делать.

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

Вопрос: спользуется ли DI в Spotify? Можете перечислить, какие технологии присутствуют в Spotify для Android, отвечаете ли вы за приложения для Android TV или только Mobile?


Dependency Injection, конечно, используется. Сложно сказать, в каких видах программирования это не используется. Мы используем фреймворк Dagger.

Какие технологии присутствуют для Android – их много разных; например, Clean Architecture – это методология разработки, которую можно по-разному имплементировать. У нас есть собственное представление и свои тулы, технологии для облегчения тестирования, все нормальные известные принципы – SOLID, например.

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

Отвечаю ли я за приложение для Android TV – нет, это отдельная команда. Mobile – это, вообще-то, тоже отдельная тема. Моя команда – это Spotify Lite; наверно, это самая сконцентрированная команда над одним приложением.

У нас есть ещё другие приложения; есть приложение Stations, оно запущено в Штатах, в Австралии, еще в нескольких странах, и есть приложение Kids для детей. Там такая же ситуация, одна команда занимается одним приложением.

У нас невероятная концентрация Android-девелоперов в одной команде; нас сейчас 5 человек таких, и мы занимаемся всем, что касается конкретного приложения. Разработкой, дизайном, user research (что пользователи думают о новых вещах в приложении), тестированием (A/B-тесты – то есть, когда мы выпускаем какую-то функциональность, мы проверяем, в каком варианте ее стоит показывать пользователям). Соответственно, мы занимаемся всем процессом релиза приложения – то есть, мы сами промоутим наше приложение в релиз, чтобы оно попало к пользователю.

Вопрос: есть ли желание перебраться в другую страну, оставаясь в Spotify?


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

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


Android-разработчики используют Java и Kotlin. Вообще, языков в Spotify много. Если вы пишете под iOS, то у вас будет Objective C и Swift; если пишете backend – будет Java, если frontend – будет много чего, в основном JS. На плюсах много чего есть, на Python. Еще очень много на Scala всяких дата-пайплайнов. Spotify процессирует очень много данных, которые пользователи присылают: про то, что они делают в приложении, про то, как они слушают музыку.

Вопрос: что такое Spotify и почему стоит его послушать?


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

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

Огромный упор был на то, что вам должно быть комфортно работать: мы понимаем, что вы работаете из дома, вы все время в одной комнате, вы перестали общаться с вашими сотрудниками – кроме тех, с которыми у вас назначены встречи. Разберитесь со своим психологическим состоянием, в первую очередь позаботьтесь о себе, потом о своих близких, потом уже организуйте свою работу. И у нас есть результаты – по-моему, Spotify уже публично хвастался, что продуктивность нашей работы во время пандемии не изменилась. Конечно, когда это все тянется уже год, то жить с этим гораздо сложнее – особенно тем, кому не нравится сидеть дома и разговаривать только с домашними. Но компания очень многое делает для того, чтобы достичь понимания. В том числе, Дэниэл Эк – глава компании Spotify – занимался доставкой первых тестов на коронавирус в Швецию.

Компания много делает для того, чтобы у вас были все возможности научиться эффективно делать свою работу, и не только. У нас верят в T-shapedness: это когда у вас есть область экспертизы (например, мобильное программирование – вы всё про него знаете), но также вы добираете вторичные навыки. Например, backend-системы в дополнение к вашему мобильному программированию. И у вас есть все возможности этому научиться на работе: у нас есть специальные курсы, и внутри Spotify есть команда, которая занимается тем, чтобы предоставлять курсы. Это когда вы на 2-3 дня ходите в классную комнату и учитесь программировать backend.

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

Еще у нас есть такая вещь, как embed – мы тут смеялись, когда в расшифровке другого интервью написали «indebt». Это когда вы внедряетесь в какую-то команду. Чаще всего это возникает тогда, когда нам нужно, чтобы команда для нас что-то сделала, и у нас какая-то зависимость на их сервис. Конечно, у них есть какие-то свои планы, и им обычно неудобно все бросать и делать прямо сейчас все для нас.

Но один человек из нашей команды может пойти к ним и помочь сделать то, что нужно нам прямо сейчас. И это необязательно какая-то мобильная разработка; это может быть backend, например. Например, я ходил embed-иться в команду, которая занимается embed-программированием: то есть, они пишут код Spotify, который внедряется во всякие встроенные девайсы – например, в колонки, вроде колонки Amazon. Я с ними работал 3 месяца, учился понимать, как это все работает. Они пишут на C встраиваемый код, очень оптимизированный, очень маленькие приложения, отлично. То есть, все эти возможности у нас есть.

Как проходит собеседование в Spotify


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

Вопрос: как попасть на работу в Spotify? Что писать и не писать в резюме, как проходит собеседование?


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

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

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

Как происходит процесс набора? Вы посылаете резюме, и, если вам достаточно повезло – рекрутер решил, что резюме подходит на позицию – то сначала с вами поговорит рекрутер; скорее всего, по телефону. Он будет выяснять простые вопросы: какую вы хотите зарплату, когда можете начать работать, надо ли вам переезжать (надо ли вас перевозить в страну).

Иногда бывает выбор, в какой стране работать, но обычно в позиции это уже написано. После этого разговора, если нас и вас все устраивает, вас приглашают на техскрининг. Это интервью на 1.5 часа. Вас просят рассказать о себе: с какими системами вы работали; нужно понять, каков ваш опыт в дизайне систем. Вот вас попросили какую-то фичу сделать — отвечаете от начала до конца: как вы ее распланировали, сделали, протестировали, выкатывали (это для мобильных приложений). Это на 10-15 минут, а потом вам будут задавать вопросы по области знаний – чтобы понять, что вы знаете, что не знаете.

Типичное: «Расскажите, что такое activity в Android». Хорошая завязка, все с этого начинают; потом можно еще много чего накопать с этого вопроса. Вам не надо отвечать на 100%, чтобы пройти: здесь просто понимают, что вы знаете и на какую позицию можете претендовать.

Потом – около 40 минут – вы будете писать какой-то код, чтобы показать, что вы умеете программировать, с подсказками решать какую-то задачу. Не требуется знать и уметь решать все задачи с leetcode до самого сложного уровня; вам просто дадут задачу, чтобы вы показали, что вы умеете программировать, логически мыслить, работать с другими людьми – потому что вам надо будет понять задачу, которую вам дали. Не просто прочитать и сразу же закодить ее молча. Нужно показать, что вы поняли задачу, задать дополнительные вопросы, спросить, какие есть ограничения на задачу.

Вам, скорее всего, скажут: «Вы должны самый лучший код написать, который вы писали в своей жизни. С тестами все прекрасно, покажите, что вы умеете».

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

Первое интервью – value, про ценности Spotify: соответствуете ли вы ценностям компании, заинтересованы ли вы в ценностях компании. Это интервью проходит по модели STAR или CAB.

STAR – это «звезда»: модель, когда вы можете кому-то давать фидбек и спрашивать фидбек. Это расшифровывается как «situation, action, result»: исходная ситуация, какое вы предприняли в этой ситуации действие, какой получился результат. Вас будут спрашивать: например, «расскажите о ситуации, когда вы обвалили production на своей работе: что вы делали, какие уроки вынесли?» И вам нужно быть готовым отвечать на подобные вопросы. Надо иметь примеры из вашей работы по различным ситуациям, нужно уметь заворачивать их в модель STAR, уметь подгонять примеры под любые вопросы, которые вам задают. Их могут задавать по-разному – а вам надо делать, как в анекдоте про блоху.

Модель CAB – «competence, achievement, behavior». Компетенции, достижения, поведение. Тоже распространенная вещь, ее не изобрели в Spotify. Competence – это про то, что у вас была какая-то задача, вы сели с ней разбираться, долго старались, и у вас получилось. Achievement – это примерно то же самое. Вы показываете, что вы стараетесь, даже если у вас не выходит. Behavior – это про поведение. Как вы себя ведете в разных ситуациях, как реагируете, какие уроки извлекаете. Я не менеджер, поэтому мне сложно это оценивать; про STAR и CAB лучше еще почитать.

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

Третье интервью – программирование в IDE (это специфично для мобильных разработчиков). Вас попросят расшарить экран, запустить IDE – обычно Android Studio, но это на ваш выбор – и написать приложение за 40 минут по задаче, которую вам дадут. Как и раньше, вам нужно будет работать с вашим интервьюером, уточнять задание, точно знать, что вы делаете, что и как вас попросили. Вы должны продумать и написать тестирование и обработку ошибок.

Четвертое интервью – system design. Здесь надо задизайнить систему. Вас попросят реализовать какую-то известную фичу из приложения, но код вы писать не будете. Вам надо будет продумать, что будет включать в себя выполнение этого задания. Вы расскажете интервьюерам, какие могут быть подводные камни при реализации. Может быть, вы что-то попробуете набросать на бумаге, чтобы понять, как все работает. Если вы графический человек, можно будет построить диаграмму. Или можно просто рассказать, как будет работать приложение, как его нужно будет программировать, как можно будет обойти сложные части. Полное планирование одной задачи.

Это все четыре интервью. После них вам присылают оффер, вы соглашаетесь на него (или нет).

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

Если вы решили, что хотите работать в Spotify, надо хорошо подготовиться к интервью, попроходить mock-интервью, пытаться проходить в другие компании (процесс интервью довольно стандартный). Не делайте так, что вы подались в Spotify, вас позвали, и это вообще ваше первое интервью – шансов на успех будет не очень много. Бывают разные случаи, конечно; мы не только старших инженеров набираем. Но джуниору тоже нужно показать, что он готов учиться и работать в этой компании. Он должен показать, что способен сделать лучше, чем другие начинающие программисты.

Сложно ли пройти интервью? Если вы хорошо подготовились – нет, не сложно. Сложно ли потом работать — зависит от того, какой вы человек и подходят ли вам ценности компании.

О Spotify Lite


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

Приложения Spotify обычно разрабатываются с расчетом на Северную Америку, Европу, где у людей хорошие телефоны, связь быстрая и не обрывается. Поэтому приложение было не очень оптимизировано. Где-нибудь в Бразилии его было сложно скачать, а потом оно запускалось долго, съедало много трафика. Все это влияет на то, приятно ли пользователями, будут ли они пользоваться приложением и покупать подписку.

Задача Spotify Lite – решить эти проблемы, убрать барьеры, которые предотвращают использование приложения. Эти проблемы – медленные телефоны, плохая или дорогая связь. У пользователей может быть любое сочетание из этих трех признаков, поэтому мы занимаемся всем спектром перфоманса. У нас одна команда, много Android-разработчиков. Приложение уже существует 2 года, основные рынки – Бразилия, Аргентина, Мексика. Мы владеем этим приложением, занимаемся всем процессом релиза.

Если вы напишете в Lite Support – может быть, я сам вам отвечу; у нас нет отдельной суппорт-команды, у нас есть разработчики, которые занимаются приложением, и они иногда читают письма в Lite Support.

Мы ездили в Бразилию и Индонезию, проверяли приложение «на земле». Это очень большая разница по сравнению с офисом с хорошим интернетом. Конечно, у нас есть network profiler, чтобы моделировать «медленный» интернет, но это все же не похоже на настоящие условия. Например, на то, что происходит, когда ты в Бразилии спускаешься в метро: между станциями может не быть никакого покрытия. В стриминг-приложении, если ты едешь достаточно долго и следующая песня не успела кэшироваться, может произойти остановка. Это очень важно понимать, важно ставить себя на место пользователя – «empathy to the user».

Про перфоманс – как работать с перфомансом. На самом деле, это довольно просто и очевидно, когда вы садитесь и на это внимательно смотрите и анализируете. Когда говоришь программисту «performance optimization», у него в голове сразу слышится «premature» — то есть, «преждевременная оптимизация перфоманса»; это не без основания так.

Перфоманс – это ситуационная и субъективная вещь. Конечно, если приложение у пользователя крашится каждые 5 минут, то это уже не перфоманс, сначала надо починить падения.

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

Все просто: вы устанавливаете текущее базовое значение метрики, мониторите изменения, предпринимаете сфокусированные попытки улучшить базовое значение, потом тестируете влияние изменений на метрику. Про все это можно прочитать в статье, которую мы написали про Spotify Lite в блоге Engineering at Spotify; там мы немного рассказываем про то, что конкретно мы делали, чтобы, например, уменьшить размер Spotify Lite.

В каждой статье про перфоманс на Android обязательно бывает цитата из Google: «на каждые 6 Мб увеличения размера скачивания мы видим уменьшение install conversion rate (когда пользователь видит приложение и решает скачать его) на процент». Это – совершенно магическая цифра. Они нигде ее не подтверждают, и она совершенно разная в разных контекстах. Если, например, уменьшить приложение размером в 10 Мб на 6 Мб, это будет очень круто. А если оно было размером в 160 Мб, то мало кто это заметит.

Вопрос: почему нет Spotify Lite на iOS?


Не имеет смысла. Очень мало старых телефонов, все покупают новые.

Вопрос: где заканчивается зона ответственности команды? Вы сами паблишите, выкатываете, отвечаете за бету?


Да, как я уже рассказывал. Мы занимаемся всем процессом паблишинга приложения.

Вопрос: Internal / Closed Track Testing?


Да, и internal, и closed, и open – все есть.

Я не успел рассказать про тулы для профилирования скорости, но это все гуглится, когда нужно что-то конкретно улучшить. Вы идете на stack overflow, начинаете искать статьи, и все находится. Android Studio очень многое предлагает для анализа перфоманса; если надо копать глубже, то вы дальше смотрите, что использует Android Studio для того, чтобы предоставлять вам эту информацию, и копаете туда с другими параметрами.

Let's block ads! (Why?)

Как я сдавал Certified Kubernetes Security

Всем привет.

Хочу поделиться своим опытом успешной сдачи экзамена Certified Kubernetes Security (CKS) от Linux Foundation. Данный экзамен, как нетрудно догадаться, проверяет наши способности настраивать различные аспекты безопасности кластера Kubernetes и приложений, работающих в нем. Экзамен мне понравился, он рассматривает безопасность с различных точек зрения, а также использует очень полезные внешние инструменты, такие как Falco, Trivy, kube-bench, Open Policy Agent, gVisor и др. Сам экзамен мне показался умеренно сложным, в отличие от CKA, который больше ориентирован на новичков в Kubernetes.

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

На текущий момент существует всего два экзамена по безопасности Kubernetes - это, собственно, сам CKS, а также Red Hat Certified Specialist in Security: Containers and OpenShift, имеющий дело с безопасностью OpenShift. Эти два экзамена во многом пересекаются, однако по Опеншифту я считаю экзамен все же сложнее (его я благополучно завалил).

Экзамен отдельно стоит стоит 300$, официальный курс Kubernetes Security Fundamentals (LFS260) стоит 299$, можно купить курс и экзамен вместе за 499$. Я купил курс и экзамен вместе за 200$ на традиционной предновогодней распродаже от Linux Foundation.

Необходимым условием для сдачи CKS является наличие действующего сертификата CKA (Certified Kubernetes Administrator). Вы можете купить CKS, но не сможете назначить экзамен, пока не получите CKA. Звучит логично, поскольку экзамен CKS является гораздо более сложным чем CKA.

Но ближе к делу. Для подготовки я использовал два курса:

  1. Официальный курс от Linux Foundation: Kubernetes Security Fundamentals (LFS260). Не хочу ничего плохого говорить о Linux Foundation, но данный курс у них вышел неудачным. Нет внятного объяснения, как работает та или иная технология или фича, сначала несколько общих красивых слов о том, какая это крутая технология, а затем сразу какая-то невнятная лаба в PDF (вы что, серьезно?!), в которой также ничего толком не объясняется. Такое ощущение, что курс делали в последнюю минуту в большой спешке. Притом, что экзамен получился очень даже неплохим.

  2. Курс на Udemy за 3599 руб. Признаться, я сильно опасался покупая "кота в мешке", однако реальность превзошла все ожидания. Курс оказался не просто полезным, он полностью раскрыл все темы экзамены, смотрелся просто на одном дыхании. К курсу прилагаются также два тестовых экзамена на https://killer.sh. Это полноценные лабы очень похожие на то, что встретится на реальном экзамене, т.е. браузерный веб-терминал справа и задачи слева. Как уверяет автор курса, эти лабы являются на самом деле усложненной версией экзамена, т.е. если вы сделаете эти лабы, то экзамен вы точно сдадите. Как выяснилось, автор был совершенно прав.

Экзамен состоит из 15-20 вопросов, продолжительность экзамена ровно 2 часа т.е. в среднем 6-8 минут на каждый вопрос. Это довольно сжатые сроки. Лично я, имея много опыта с Kubernetes и просмотрев два курса и сделав два тестовых экзамена на killer.sh, уложился в 1 час 40 минут.

Проходной балл на экзамене 67%, что на мой взгляд довольно демократично. Экзамен легким не назовешь, но низкий проходной балл видимо призван сгладить этот "недостаток".

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

Теперь самое интересное - темы экзамена. Официальный список тем можно посмотреть на странице описания CKS. На всякий случай продублирую его здесь:

Список тем экзамена

Cluster Setup (10%)

  1. Use Network security policies to restrict cluster level access

  2. Use CIS benchmark to review the security configuration of Kubernetes components (etcd, kubelet, kubedns, kubeapi)

  3. Properly set up Ingress objects with security control

  4. Protect node metadata and endpoints

  5. Minimize use of, and access to, GUI elements

  6. Verify platform binaries before deploying

Cluster Hardening (15%)

  1. Restrict access to Kubernetes API

  2. Use Role Based Access Controls to minimize exposure

  3. Exercise caution in using service accounts e.g. disable defaults, minimize permissions on newly created ones

  4. Update Kubernetes frequently

System Hardening15%

  1. Minimize host OS footprint (reduce attack surface)

  2. Minimize IAM roles

  3. Minimize external access to the network

  4. Appropriately use kernel hardening tools such as AppArmor, seccomp

Minimize Microservice Vulnerabilities (20%)

  1. Setup appropriate OS level security domains e.g. using PSP, OPA, security contexts

  2. Manage Kubernetes secrets

  3. Use container runtime sandboxes in multi-tenant environments (e.g. gvisor, kata containers)

  4. Implement pod to pod encryption by use of mTLS

Supply Chain Security20%

  1. Minimize base image footprint

  2. Secure your supply chain: whitelist allowed registries, sign and validate images

  3. Use static analysis of user workloads (e.g.Kubernetes resources, Docker files)

  4. Scan images for known vulnerabilities

Monitoring, Logging and Runtime Security20%

  1. Perform behavioral analytics of syscall process and file activities at the host and container level to detect malicious activities

  2. Detect threats within physical infrastructure, apps, networks, data, users and workloads

  3. Detect all phases of attack regardless where it occurs and how it spreads

  4. Perform deep analytical investigation and identification of bad actors within environment

  5. Ensure immutability of containers at runtime

  6. Use Audit Logs to monitor access

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

Экзамен реально интересный и при подготовке я узнал много нового. Больше всего мне понравилась тулза под названием Falco от Sysdig. Эта тулза мониторит системные вызовы ядра Linux и поднимает алерты, если обнаруживает подозрительную активность. В комплекте с Falco идет множество полезных предустановленных правил, например:

  1. Запуск привилегированного контейнера или запуск контейнера с hostPID или hostNetwork

  2. Попытка контейнера примонтировать важные хостовые директории через hostPath

  3. Попытка повышения привилегий процессом в контейнере

  4. Попытка процессов читать или писать в важные системные файлы, например в каталоге /etc

  5. Попытка открыть сетевое соединение с IP-адресами не из разрешенного списка

  6. Установка пакетов в контейнере

и многие другие.

Помимо этого, Falco поддерживает мониторинг аудит логов Kubernetes, позволяя поднимать алерты в случае подозрительной активностей на уровне Kubernetes API, например:

  1. Создание привилегированного контейнера или запуск контейнера с hostPID или hostNetwork.

  2. Создание неймспейсов

  3. Запуск контейнера не из разрешенного списка имейджей

  4. Запуск подов в неймспейсе kube-system

  5. Создание ClusterRoleBinding с cluster-admin кластер ролью

и опять же многие другие.

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


Если мы хотим иметь больше контроля над изменениями в кластере Kubernetes, при этом стандартного RBAC нам недостаточно, то в курсе описывается еще один инструмент под названием Open Policy Agent (OPA). Этот инструмент позволяет отслеживать соответствие объектов в Kubernetes определенным политикам безопасности, которые описываются на языке описания политик Rego. В Kubernetes он ставится в виде validating admission webhook под названием OPA Gatekeeper. Сами политики описываются в виде Custom Resource Definition. Вот пример политики, которая требует при создании или изменении неймспейса обязательного наличия лейбла costcenter.

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        
        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-costcenter
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["costcenter"]

При попытке создания неймспейса без лейбла costcenter вылезет ошибка:

Error from server (you must provide labels: "costcenter"): error when creating "ns.yaml": admission webhook "validating-webhook.openpolicyagent.org" denied the request: you must provide labels: "costcenter"

Возможности OPA Gatekeeper постоянно расширяются, например он может работать в режиме аудита, т.е. лишь информировать об объектах Kubernetes, которые не соответствуют политике, но не запрещать их создание. Помимо этого, существует возможность переключить Gatekeeper в режим mutating webhook, т.е. автоматически приводить объекты в соответствие политике, например добавлять нужные лэйблы.

Кстати, у языка Rego есть собственный playground, в котором можно потестировать политики. Также, там есть ряд примеров политик для Kubernetes, что очень удобно.

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

Другие темы экзамена:

  1. Network Policy. Тут все довольно просто, однако нужно знать про один важный нюанс from и to селекторов. В целом проблем с сетевыми политиками возникнуть не должно.

  2. RBAC. Очень важно понимать разницу между Role и ClusterRole, RoleBinding и ClusterRoleBinding. Также надо помнить, что с ClusterRole можно создать ClusterRoleBinding, в этом случае эта роль будет действовать на всем кластере, а можно создать и простой RoleBinding, в таком случае ClusterRole будет действовать только в пределах одного неймспейса (самый частый пример, это кластерные роли admin, edit и view, которые можно давать юзерам на конкретные неймспейсы).
    В отличие от этого с Role можно создавать только RoleBinding, то есть простая роль всегда существует и ограничена неймспейсом, в котором она существует. Существование двух ролей с одним именем в двух разных неймспейсах совершенно легально, хотя вряд ли это можно назвать хорошей практикой.
    Также, очень важно понимать, для чего нужны сервисаккаунты, и как можно авторизовываться в кластере с их токеном ("Authorization: Bearer $TOKEN" и все такое).

  3. Аудит логи Kubernetes. Нужно уметь настраивать аудит логи как в связке с Falco, так и простое логирование в файл. Нужно уметь писать политику аудита, также иметь представление о флагах kube-apiserver, которые связаны с настройками аудит логов.

  4. Kube-bench. Нужно уметь пользоваться тулзой и исправлять найденные тулзой потенциальные бреши в безопасности кластера.

  5. Уметь работать с флагами запуска kube-apiserver, kube-scheduler, kube-controller-manager и kubelet. Поскольку в экзамене встречаются только кластеры, созданные с помощью kubeadm, то исправление манифестов не представляет большого труда. Нужно только помнить о том, что если после исправление манифеста, компонент в течение минуты не запускается, то нужно идти и смотреть логи (/var/log/pods/*), т.к. скорее всего допущена опечатка или ошибка в манифесте.

  6. Апгрейд kubeadm кластера.

  7. Статический анализ безопасности YAML-манифестов Kubernetes и Докерфайлов. Здесь нужно просто смотреть глазами и находить потенциально небезопасные участки кода, например запуск контейнера от рута, использование секретов, излишние привилегии и др.

  8. TLS-enabled Ingress.

  9. ImagePolicyWebhook.

  10. AppArmor. Нужно уметь включить профиль AppArmor на ноде и запустить под с данным профилем. Писать профили с нуля уметь не нужно (фух!)

  11. Seccomp. Требование те же, что и с AppArmor.

  12. Запускать поды с альтернативными RuntimeClass, типа gVisor. Знать, как их устанавливать, не нужно.

  13. PodSecurityPolicy. Нужно помнить, что PodSecurityPolicy частично носит запрещающий характер, т.е. может отклонять поды с небезопасными настройками, но также частично может вносить изменения в настройки подов, например принудительно запускать поды с AppArmor профилями и управлять дефолтными настройками, например defaultAllowPrivilegeEscalation и defaultAddCapabilities.

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

Во время экзамена можно открывать одну и только одну дополнительную вкладку браузера с документацией (кстати, у меня экзамен не запустился на Chrome, пришлось установить Vivaldi). Разрешены следующие ресурсы:

  1. https://kubernetes.io/docs

  2. https://github.com/kubernetes

  3. https://kubernetes.io/blog

  4. https://github.com/aquasecurity/trivy

  5. https://docs.sysdig.com

  6. https://falco.org/docs

  7. https://gitlab.com/apparmor/apparmor/-/wikis/Documentation

В принципе, этих ресурсов более чем достаточно. Большая часть всего необходимого всегда находится на https://kubernetes.io/docs.

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

Let's block ads! (Why?)