Перформанс, как и security, в большой степени состоит в том числе и из процессов. Что надо сделать, чтобы не повторять ошибок, как найти плохие паттерны в коде на этапе компиляции или как мерить производительность, latency, как знать к каким сервисам обращаться, как сконнектить людей из hardware, firmware, software и тд. Как обучить людей, чтобы они писали быстрый код.
Это сложный и непростой процесс. Например, в Google мы всё больше и больше переходим на политику third_party live at head. Когда мы автоматически подбираем обновлённые версии веток того или другого контриба (библиотек из open source).
Например, мы релизим LLVM пару раз в месяц. Да, мы гоняем компилятор на всём коде Google, и откатываем то, что не работает сразу. Иногда ломаются другие контрибы, и мы патчим их. Иногда не работает наш код, и мы его фиксим. Эдакий стресс тест компилятора каждые пару недель. Зато мы можем компиляторным инженерам повысить velocity, они что-то комитят, а через две недели оно в проде на огромную кодовую базу. Об этом мы писали в книжке Software Engineering at Google.
Недавно пара наших инженеров ядра Andrew Delgadillo и Dylan Hatch поделились то, как мы переходим на жизнь at head в Linux.
Исторически так сложилось, что ядро Linux разрабатывалось отдельно и поэтому в проде до сих пор у нас версия 4.15, когда как уже вышла 5.15, несколько лет уже прошло, а мы всё ещё не можем переехать.
И да, остро вопрос не стоял раньше, взяли ядро, наложили пару патчей и обновили. А потом поняли, что оптимизация Linux стоит больших денег Google, и наняли людей на разработку ядра. Тем самым мы сейчас находимся в состоянии 9000 (9 тысяч) патчей поверх mainline. Многие из них драйвера для некоторого нашего железа, например, TPU, но есть и более сложные вещи, как Google Fibers (более лёгкие user-space треды), много патчей о том, как находить Out Of Memory проблемы быстрее и лучше (дада, мы считаем, что внутри мы пофиксили баг 12309), отключение сбора perf стеков из-за приватности и так далее. Называем мы это ядро Prodkernel, потому что оно ядро и работает в проде.
И в последнее время мы стали умирать обновлять Linux, это занимало десятки инженеров месяцев, особенно было много проблем с тестированием, и мы находили проблемы в версиях ядра, которые уже давным давно на суппорте и процесс фиксов растягивался на ещё месяцы.
В последнее время всё больше и больше мы уделяем время тому, как обновлять ядро. Назвали мы этот проект Icebreaker, потому что это уже невозможно и надо ломать этот лёд.
Да, у этого есть риски. Иногда Linux community может сказать, что им что-то не надо, и мы останемся с патчами. Иногда мы что-то проглядим, и в проде будет упячка. Но разработчики ядра в Google нацелены на удаление ненужных патчей, апстрима всех нужных, ну а с драйверами как-нибудь разберёмся.
Prodkernel с нами ещё поживет несколько лет, но Icebreaker это то, куда мы стремимся и тратим очень много сил. Выкатка на супер боевое окружение ядра за считанные дни, нахождение всех багов, размазанный процесс фикса багов и апстрим многих фич от Google должны достаточно сильно прокачать как и open source, так и нас внутри.
Я точно знаю, что некоторые вице-президенты Google не очень любят такие решения, но их всё таки убедили более технические люди. Google не сможет нанять такую команду разработки, которая будет мощнее всего community большого опен-сорса. Мы за несколько лет едва сделали Fuchsia OS, которая ни разу не про серверы. И даже если писать свою, то это годы разработки и десятки лет обучения людей.
Некоторые низкоуровневые компоненты настолько важны для tech мира, что закрываться просто нельзя. Security патчи должны быть понятны всем, какие атаки могут быть сделаны в каких версиях, и какие патчи в каких версиях улучшали перформанс.
Я горд за команду ядра, что они наконец-то официально поделились об этом с миром.
[1] Заметка от Andrew Delgadillo и Dylan Hatch про разработку ядра в Google. Слайды
[2] Бесплатная книжка по Software Engineering at Google
Это сложный и непростой процесс. Например, в Google мы всё больше и больше переходим на политику third_party live at head. Когда мы автоматически подбираем обновлённые версии веток того или другого контриба (библиотек из open source).
Например, мы релизим LLVM пару раз в месяц. Да, мы гоняем компилятор на всём коде Google, и откатываем то, что не работает сразу. Иногда ломаются другие контрибы, и мы патчим их. Иногда не работает наш код, и мы его фиксим. Эдакий стресс тест компилятора каждые пару недель. Зато мы можем компиляторным инженерам повысить velocity, они что-то комитят, а через две недели оно в проде на огромную кодовую базу. Об этом мы писали в книжке Software Engineering at Google.
Недавно пара наших инженеров ядра Andrew Delgadillo и Dylan Hatch поделились то, как мы переходим на жизнь at head в Linux.
Исторически так сложилось, что ядро Linux разрабатывалось отдельно и поэтому в проде до сих пор у нас версия 4.15, когда как уже вышла 5.15, несколько лет уже прошло, а мы всё ещё не можем переехать.
И да, остро вопрос не стоял раньше, взяли ядро, наложили пару патчей и обновили. А потом поняли, что оптимизация Linux стоит больших денег Google, и наняли людей на разработку ядра. Тем самым мы сейчас находимся в состоянии 9000 (9 тысяч) патчей поверх mainline. Многие из них драйвера для некоторого нашего железа, например, TPU, но есть и более сложные вещи, как Google Fibers (более лёгкие user-space треды), много патчей о том, как находить Out Of Memory проблемы быстрее и лучше (дада, мы считаем, что внутри мы пофиксили баг 12309), отключение сбора perf стеков из-за приватности и так далее. Называем мы это ядро Prodkernel, потому что оно ядро и работает в проде.
И в последнее время мы стали умирать обновлять Linux, это занимало десятки инженеров месяцев, особенно было много проблем с тестированием, и мы находили проблемы в версиях ядра, которые уже давным давно на суппорте и процесс фиксов растягивался на ещё месяцы.
В последнее время всё больше и больше мы уделяем время тому, как обновлять ядро. Назвали мы этот проект Icebreaker, потому что это уже невозможно и надо ломать этот лёд.
Да, у этого есть риски. Иногда Linux community может сказать, что им что-то не надо, и мы останемся с патчами. Иногда мы что-то проглядим, и в проде будет упячка. Но разработчики ядра в Google нацелены на удаление ненужных патчей, апстрима всех нужных, ну а с драйверами как-нибудь разберёмся.
Prodkernel с нами ещё поживет несколько лет, но Icebreaker это то, куда мы стремимся и тратим очень много сил. Выкатка на супер боевое окружение ядра за считанные дни, нахождение всех багов, размазанный процесс фикса багов и апстрим многих фич от Google должны достаточно сильно прокачать как и open source, так и нас внутри.
Я точно знаю, что некоторые вице-президенты Google не очень любят такие решения, но их всё таки убедили более технические люди. Google не сможет нанять такую команду разработки, которая будет мощнее всего community большого опен-сорса. Мы за несколько лет едва сделали Fuchsia OS, которая ни разу не про серверы. И даже если писать свою, то это годы разработки и десятки лет обучения людей.
Некоторые низкоуровневые компоненты настолько важны для tech мира, что закрываться просто нельзя. Security патчи должны быть понятны всем, какие атаки могут быть сделаны в каких версиях, и какие патчи в каких версиях улучшали перформанс.
Я горд за команду ядра, что они наконец-то официально поделились об этом с миром.
[1] Заметка от Andrew Delgadillo и Dylan Hatch про разработку ядра в Google. Слайды
[2] Бесплатная книжка по Software Engineering at Google