Привет, я как раз из команды SRE в Додо. Тут произошла небольшая путаница в понятиях. Полноценные SRE у нас есть не только в одноимённой команде: есть разработчики, основной фокус которых – на надёжности конкретных сервисов. В этом месте довольно близко к книжке: сервисы должны передаваться к SRE на LTS только, когда сервисы feature complete. У нас таких сервисов почти нет: разработчики поддерживают свои сервисы end-to-end: код, пайплайн, продакшн.
То есть пайплайны за разработчиков мы не пишем, хотя свои домашние инструменты для деплоя у нас есть.
Сама команда SRE тоже довольно близка к книжке: "SRE is a software engineering approach to IT operations". Наша команда почти целиком состоит из инженеров с бэкграундом в разработке. Мы сфокусированы на надёжности и стоимости инфраструктуры, помогаем разработчикам с их сервисами, когда надо. И стараемся делать инструменты, которые делают operations проще: мониторинг, disaster recovery, инструменты для того, чтобы разработчик сам мог сделать всё что считает правильным и не ошибиться.
Мы как компания только сейчас выходим из режима стартапа. Как команда приходим к тому, чтобы не быть "многорукими многоногами", а разделяться по компетенциям. Хотя органическое разделение, конечно, есть давно.
Первый пример: В mysql innodb локи могут быть вызваны не только конкурентным доступом к одной строке. Достаточно сделать апдейт с условием не по уникальному ключу, а по какому-то другому индексируемому полю или по полю без индекса (не надо так). В случае с индексируемым полем мы получим gap lock, который может не дать в инсертить. Это можно отключить, но чтобы это сделать, надо понимать что ты делаешь.
Второй пример: тогда очень много интересного делалось в рамках одной транзакции. Даже вещи, которые могли бы перетерпеть eventual consistency происходили разом. И тут может стрельнуть AUTO-INC лок. Если транзакций много и все они хотят сделать инсерт в одну таблицу (а именно это они хотят сделать), то auto-inc заставляет их ждать своей очереди. Хотя это и не сильно страшно, если транзакции шустрые. Ужасное случится, если частота появления новых записей станет выше, чем частота вставки. Тогда проблема вырастет в снежный ком и посыпятся таймауты. Вот такие вещи хорошо или оптимизировать (например, заменить autoincrement на внешнюю генерацию Uuid) или делать асинхронными, а лучше и то и другое.
В опенсорс мы выкладываем сейчас меньше, чем могли бы.
В существующие проекты контрибьютим. Особенно в инфраструктурые – хэлм чарты, экспортеры для прометея. Наш разработчик недавно сделал самый быстрый генератор UUID на C# и выложил в опенсорс как пакет (статья, говорят, на подходе, но это не точно).
Свои проекты не выкладывали в опенсорс, до этого не доходят руки. Такие вещи хочется делать хорошо, с поддержкой, а не просто выбрасывать в паблик чтобы валялось.
Ну, я готов помочь найти то что после знака вопроса :)
Вот кусочек выступлений с конференций (BackendConf, RootConf, DevopsConf, Highload++, AgileDays, Стачка, TeamLeadConf, WhaleRider, UWDC). Думаю, это даже не четверть выступлений за последние 2-3 года.
Выглядит как троллинг. Я не видел обратной стороны луны, но это не значит что её не существует.
Видимые внешнему наблюдателю артефакты разработки – приложение, сайт, бэкофис. Какие-то другие артефакты должны быть у айти? Ну, тогда мы выступаем на конференциях и проводим митапы сами. Статьи на хабре пишем. Немного контрибьютим в опенсорс.
Я без подтекста. В 2010ом Рамблеру было публично норм, что Сысоев «ушёл» с nginx'ом, и ему осознанно было ок продолжать использовать nginx с доработками от Сысоева для своего кор-бизнеса.
> Ну так историю этих аутеджей можно посмотреть и спланировать стратегию для своего сервиса.
Смысл аутеджей, в том, что их сложно предсказывать. Мы же говорим не про плановую поддержку.
Ну и да, мы сделали как вы советуете: спланировали, что в перспективе должны иметь план в виде второго облака / независимого ДЦ. (Это не только из-за отказов облаков, но и из-за правовых причин)
> возможно нельзя использовать managed db
on-premise машины тоже будут падать, сеть до них тоже будет теряться. Естественно, если это критический путь в системе, он должен быть достаточно надёжен, чтобы самовосстановиться и продолжить работать. Мы так и делаем.
Второй ДЦ берётся не из воздуха, а из попытки достичь большего количества «девяток», чем может предложить одно облако. Объяснять бизнесу, что ажур (амазон, гугл) сломался во всём мире и мы ничего не можем с этим поделать – слабая позиция.
> Ничего нового клауд в этом смысле не привнес.
Согласен
А ещё у каждого клауд провайдера бывают глобальные аутеджи. У того же ажура была недавно история, когда DNS на managed базы лежал час. Или нетворк между датацентрами 6 часов лежал без предсказания, когда поднимется.
Это происходит очень редко, но в такие моменты или уже должна быть готова инфраструктура на другом облаке, либо должна быть возможность, инструкции и подготовленный плацдарм, чтобы быстро развернуться на другом облаке и переключить на него трафик.
Более того, я ещё и с редактором в паре сидел, чтобы текст читался лучше :) А редактор смотрела на клавиатуру) Зуб даю — оригинал был без подглядываний.
Там буквально в следующем предложении я раскрыл, что имел ввиду.
Список вещей, к которым я решил вернуться и изучить заново начинался с пункта "слепая печать". Условно, это первый гештальт в списке. Он один не прорвёт потолок, но помогает двигаться быстрее по другим пунктам.
Второй пункт из списка я раскрыл в комментах: базовые команды в linux без мана и stackoverflow. Он второй именно потому, что базовые команды приходят на помощь в ситуациях, когда ты один на один с проблемой, иногда на голом сервере.
Тут лучше печатать быстро и без ошибок, чем на удачу копипастить из stackoverflow. Но это другая история. Закрою гештальт, обязательно расскажу.
Я заглядываюсь на дворак, но всё ещё считаю его за экзотику. Тем более, что у нас парные станции универсальные, и если заточить себя под дворак, нужно или всю компанию на него перетягивать, либо себя изолировать.
Нет, количество не перерастает в качество. Но, работать человек может лишь ограниченное количество времени в сутки: 4-12 часов в рамках задачи. И если не очень умный конфиг, который нужно написать один раз, занимает больше чем 5 минут – я спотыкаюсь и перестаю получать удовольствие. И насколько я вижу, многие другие тоже. А некоторые настолько залипают на таких задачах, что приходят только через пару дней измотанные и каплями пота на лбу.
Так что да, иногда чем больше и быстрее — тем качественнее.
Привет, я как раз из команды SRE в Додо. Тут произошла небольшая путаница в понятиях. Полноценные SRE у нас есть не только в одноимённой команде: есть разработчики, основной фокус которых – на надёжности конкретных сервисов. В этом месте довольно близко к книжке: сервисы должны передаваться к SRE на LTS только, когда сервисы feature complete. У нас таких сервисов почти нет: разработчики поддерживают свои сервисы end-to-end: код, пайплайн, продакшн.
То есть пайплайны за разработчиков мы не пишем, хотя свои домашние инструменты для деплоя у нас есть.
Сама команда SRE тоже довольно близка к книжке: "SRE is a software engineering approach to IT operations". Наша команда почти целиком состоит из инженеров с бэкграундом в разработке. Мы сфокусированы на надёжности и стоимости инфраструктуры, помогаем разработчикам с их сервисами, когда надо. И стараемся делать инструменты, которые делают operations проще: мониторинг, disaster recovery, инструменты для того, чтобы разработчик сам мог сделать всё что считает правильным и не ошибиться.
Мы как компания только сейчас выходим из режима стартапа. Как команда приходим к тому, чтобы не быть "многорукими многоногами", а разделяться по компетенциям. Хотя органическое разделение, конечно, есть давно.
Первый пример: В mysql innodb локи могут быть вызваны не только конкурентным доступом к одной строке. Достаточно сделать апдейт с условием не по уникальному ключу, а по какому-то другому индексируемому полю или по полю без индекса (не надо так). В случае с индексируемым полем мы получим gap lock, который может не дать в инсертить. Это можно отключить, но чтобы это сделать, надо понимать что ты делаешь.
Второй пример: тогда очень много интересного делалось в рамках одной транзакции. Даже вещи, которые могли бы перетерпеть eventual consistency происходили разом. И тут может стрельнуть AUTO-INC лок. Если транзакций много и все они хотят сделать инсерт в одну таблицу (а именно это они хотят сделать), то auto-inc заставляет их ждать своей очереди. Хотя это и не сильно страшно, если транзакции шустрые. Ужасное случится, если частота появления новых записей станет выше, чем частота вставки. Тогда проблема вырастет в снежный ком и посыпятся таймауты. Вот такие вещи хорошо или оптимизировать (например, заменить autoincrement на внешнюю генерацию Uuid) или делать асинхронными, а лучше и то и другое.
В существующие проекты контрибьютим. Особенно в инфраструктурые – хэлм чарты, экспортеры для прометея. Наш разработчик недавно сделал самый быстрый генератор UUID на C# и выложил в опенсорс как пакет (статья, говорят, на подходе, но это не точно).
Свои проекты не выкладывали в опенсорс, до этого не доходят руки. Такие вещи хочется делать хорошо, с поддержкой, а не просто выбрасывать в паблик чтобы валялось.
Вот кусочек выступлений с конференций (BackendConf, RootConf, DevopsConf, Highload++, AgileDays, Стачка, TeamLeadConf, WhaleRider, UWDC). Думаю, это даже не четверть выступлений за последние 2-3 года.
www.youtube.com/watch?v=MN3Rd5n8cm0
www.youtube.com/watch?v=AZHPtgs2rck
www.youtube.com/watch?v=7DxxekjWokE
www.youtube.com/watch?v=sLDYgmhNxfU
www.youtube.com/watch?v=xe-MMA5K0fY
www.youtube.com/watch?v=DWfJWCWV_eQ
www.youtube.com/watch?v=gflehZgVoKw
www.youtube.com/watch?v=Sbjj-LrCHoM
www.youtube.com/watch?v=QpXWx4HC4WA
Видимые внешнему наблюдателю артефакты разработки – приложение, сайт, бэкофис. Какие-то другие артефакты должны быть у айти? Ну, тогда мы выступаем на конференциях и проводим митапы сами. Статьи на хабре пишем. Немного контрибьютим в опенсорс.
vimeo.com/10831777
nginx.org/en/CHANGES-0.7
Смысл аутеджей, в том, что их сложно предсказывать. Мы же говорим не про плановую поддержку.
Ну и да, мы сделали как вы советуете: спланировали, что в перспективе должны иметь план в виде второго облака / независимого ДЦ. (Это не только из-за отказов облаков, но и из-за правовых причин)
> возможно нельзя использовать managed db
on-premise машины тоже будут падать, сеть до них тоже будет теряться. Естественно, если это критический путь в системе, он должен быть достаточно надёжен, чтобы самовосстановиться и продолжить работать. Мы так и делаем.
Второй ДЦ берётся не из воздуха, а из попытки достичь большего количества «девяток», чем может предложить одно облако. Объяснять бизнесу, что ажур (амазон, гугл) сломался во всём мире и мы ничего не можем с этим поделать – слабая позиция.
> Ничего нового клауд в этом смысле не привнес.
Согласен
Это происходит очень редко, но в такие моменты или уже должна быть готова инфраструктура на другом облаке, либо должна быть возможность, инструкции и подготовленный плацдарм, чтобы быстро развернуться на другом облаке и переключить на него трафик.
Подробно я постраюсь написать статью к концу года.
Там буквально в следующем предложении я раскрыл, что имел ввиду.
Список вещей, к которым я решил вернуться и изучить заново начинался с пункта "слепая печать". Условно, это первый гештальт в списке. Он один не прорвёт потолок, но помогает двигаться быстрее по другим пунктам.
Второй пункт из списка я раскрыл в комментах: базовые команды в linux без мана и stackoverflow. Он второй именно потому, что базовые команды приходят на помощь в ситуациях, когда ты один на один с проблемой, иногда на голом сервере.
Тут лучше печатать быстро и без ошибок, чем на удачу копипастить из stackoverflow. Но это другая история. Закрою гештальт, обязательно расскажу.
Я там в других комментариях постарался раскрыть, почему это про программирование.
Ну и работа программиста, это не только программный код, но иногда и документация и переписка.
Я заглядываюсь на дворак, но всё ещё считаю его за экзотику. Тем более, что у нас парные станции универсальные, и если заточить себя под дворак, нужно или всю компанию на него перетягивать, либо себя изолировать.
Так что да, иногда чем больше и быстрее — тем качественнее.