Соглашусь и дополню. С оговоркой, что, конечно, российские компании (Яндекс, Сбер, Тинькофф) вообще никак в исследовании не участвовали, а «средняя температура по больнице» скрывает очень многое. Примечательно, что авторы и сами подчеркивают: нет единого рецепта.
Как мне показалось, ваши наблюдения где‑то пересекаются и с самим исследованием, и с выводами оригинальной статьи.
Зависимость от команды и управления
Исследователи прямо говорят об этом: «Несомненно, это зависит от обстоятельств, организации, характера работы, выполняемых задач и самого человека». Они хорошо проехались и по начальникам, которые предпочитают стоять над душой: «Для успешной децентрализации (коей является удаленка) компания должна быть особенно хорошо управляема. Чем слабее менеджмент, тем сильнее стремление вернуть всех в офис», — тут не дословно, а скомпилированная мысль.
Квоты и гибридный формат
Упомянутая квота в Сбере (70% в офисе) — яркий пример того, к чему, согласно прогнозам, и движется большинство компаний. Почти все руководители — за гибрид. Так что политика Сбера — не столько отрицание удаленки, сколько реализация самого популярного гибридного сценария.
Выбор сотрудников и «утечка мозгов»
Пример про знакомых, уехавших в теплые страны, — тоже прямое подтверждение одного из главных выводов статьи. Авторы прогнозируют: «Сотрудники будут тяготеть к фирмам с более гибкой политикой». Это не что иное, как колоссальное конкурентное преимущество в борьбе за таланты — просто не всем компаниям оно требуется.
Специфика (безопасность, госсектор)
Требования к безопасности и работе из РФ — такой пласт вопросов, который американское исследование, конечно, не охватывает. Я лично тут воздержусь от комментариев. Вообще то, как люди решают проблемы с формальными запретами — невероятно интересная, но уже совсем другая тема. Я даже не знаю, есть ли такое исследование. Было бы интересно с ним познакомиться.
Главная ценность этой статьи 23-го года — в долгосрочных прогнозах и анализе фундаментальных трендов, которые не так быстро меняются. Опрос, на который ссылаются авторы, просил руководителей заглянуть на пять лет вперед, до 2028 года. То есть анализируется не сиюминутная ситуация, а долгосрочные ожидания топ‑менеджеров.
Исследование выделяет несколько причин, почему удаленная работа останется надолго, и они носят не временный, а структурный характер.
Вынужденный эксперимент. Миллионы компаний и сотрудников были вынуждены попробовать удаленку — их желания никто не спрашивал. Опыт для многих оказался лучше, чем ожидалось — отношение к такому формату изменилось навсегда.
Инвестиции в инфраструктуру. И сотрудники, и компании вложили значительные средства и время в обустройство домашних офисов и разработку ПО. В среднем каждый работник потратил на это 15 часов и $561 — но это только меры в период срочности.
Сдвиг отношения. Работа из дома часто воспринималась как «отлынивание». Массовый переход изменил восприятие: две трети опрошенных отметили, что отношение к удаленке среди их знакомых улучшилось.
Инновации. Резкий рост рынка удвоил число патентов на технологии, которые поддерживают удаленку: видеоконференции, средства для совместной работы и т. д. Технологический прогресс в этой области «раскрутился» и уже сам влияет на рынок.
Конкретные цифры (например, 28% работающих из дома) со времени выхода оригинальной статьи могут колебаться, но выводы и прогнозы того, что удаленка надолго, остаются актуальными.
Трудно не согласиться. Экономия времени на дорогу — одно из главных преимуществ удаленки.
Цифра в 8% — это усредненный результат. Участникам задавали прямой вопрос: «На какое снижение зарплаты вы готовы пойти ради возможности работать из дома 2−3 дня в неделю?» Это субъективная оценка самими опрашиваемыми, а не расчет, основанный на времени в пути.
В исследовании есть даже цифры и повыше. Среднее время до работы и обратно — 54 минуты в день. Выяснилось, что оно напрямую зависит от уровня дохода:
те, у кого выходит менее $30 000 в год, тратили на дорогу в одну сторону в среднем менее 22 минут.
кто зарабатывает $150 000 до $250 000 — уже около 44 минут в одну сторону.
Исследование напрямую не учитывает время на «подготовку к работе». Правильнее было бы его тоже считать частью тех самых выгод и суммировать в общей оценке.
Автор оригинальной статьи пишет об IT с тех пор, как CP/M стала самой популярной операционной системой. Мне кажется, если просто сказать «журналист» — на ум может прийти неверная ассоциация.
Речь не о том, что «самое простое действие от нажатия enter при команде git push» стало дольше. Ключевая метрика, о которой говорится, — Lead time for code changes — измеряет время от момента коммита кода до его успешного запуска в production. Сюда входит вся цепочка: сборка, тестирование, развертывание и т. д., а не только git push.
Для многих (41% в Q1 2024) доставка изменений действительно превращается в «квесты» на месяц. Доля таких команд выросла (в Q3 2020 их было 34%). В то же время сегмент наиболее быстрых команд, у которых этот процесс занимает менее одного дня, остается относительно стабильным (14% в Q1 2024).
Смысл статьи (и отчета, на котором она основана) — показать актуальное состояние DevOps, оценить эффективность доставки ПО, а также выявить факторы, которые на всё влияют.
Отчет предполагает, что одна из причин наблюдаемых трендов — рост сложности проектов, который нивелирует некоторые выгоды от внедрения DevOps. Я не возьмусь делать самостоятельные выводы, так это или нет. Мне показались интересными и само исследование, и оригинальная статья, которая является его обзором.
Отчасти соглашусь, но своего мнения высказывать не стану, так как не считаю себя вправе спорить по этому вопросу. Поскольку тема мне очень интересна, я постарался разобраться в отчете (насколько смог) и попробую ответить как бы от имени автора оригинальной статьи. Замечу, что не полностью разделяю его взгляды, да и он сам не выходит за рамки выводов State of CI/CD Report, поэтому и я буду отталкиваться от того же отчета.
Необходимость выкатить только что написанный код в продакшн
Не каждый коммит предназначен для немедленного развертывания. Отчет же, как я понял, стремится к тому, чтобы команды имели возможность безопасно и быстро это делать при необходимости.
Lead time for code changes
Высокие показатели здесь не обязательно означают, что все коммиты идут в прод немедленно, а процесс отлажен и быстр. Хотфиксы, требуют скорости, а эффективные CI/CD пайплайны этому способствуют. Отчет показал, что только 14% разработчиков могут задеплоить код за день, 41% же вообще тратят на это месяц.
Скорость деплоя и ее неоднозначность
В отчете речь идет про Deployment frequency — одну из ключевых метрик DORA. Она измеряет частоту развертывается кода (стр. 21 отчета). При этом метрика никак не оценивает сложность каждого конкретного развертывания (будь то смена ID образа или создание нового пайплайна). Она отражает общую способность команды регулярно поставлять работающий код.
«Пилить новые пайплайны/манифесты»
Сложность подготовки к развертыванию скорее отразится на Lead time for code changes — время, затраченное до того, как изменение будет готово к деплою и запущено. Цель — сделать даже сложные развертывания более управляемыми и менее трудоемкими (за счет автоматизации и стандартизации).
Отчет не смешивает maintenance и development с точки зрения самих задач. Однако результативность процессов доставки ПО действительно оценивается в целом — тут не поспоришь.
Восстановление сервиса в течение недели и SLA/RTO
Вы совершенно правы, что SLA и RTO (Recovery Time Objective) — это бизнес-параметры, которые и определяют допустимое время простоя. Метрика DORA Time to restore service как раз измеряет, сколько времени уходит на восстановление сервиса после незапланированного сбоя (стр. 22).
С точки зрения DORA, это показатель операционной эффективности команды. Даже если SLA позволяет сервису «валяться дольше», способность быстро восстанавливаться — это признак зрелости процессов, качества архитектуры и экспертизы команды.
Действительно, если SLA не нарушен, формально «нет проблемы» с точки зрения контракта. Но с точки зрения конкурентоспособности, удовлетворенности клиентов и репутации бизнеса, длительные простои редко бывают желательны, даже если укладываются в SLA. Исследование стремится улучшить именно фактическую способность быстрого восстановления.
Кризис в качестве управления проектами и другие факторы
Ваше наблюдение о том, что описанные проблемы могут указывать на более глубокие системные недочеты в управлении, перекликается с некоторыми выводами отчета:
подчеркивается «важная роль, которую организации и руководители команд играют в направлении своих команд к более высокой производительности»;
указывается на необходимость «обеспечить, чтобы новые разработчики были лучше знакомы с DevOps в целом, а также с практиками, используемыми в организации»;
отмечается, что некоторые организации не внедряют и не стандартизируют лучшие практики, что приводит к зависимости производительности от индивидуального опыта разработчиков — это тоже можно рассматривать как недостатки в управлении.
Я о том же примерно написал, что не все сбои одинаковы. Согласен с вами — степень тяжести можно оценивать по времени, нужном для восстановления сервиса. И говорим мы, конечно, чисто о технической стороне (без учета репутационных и прочих сопутствующих потерь).
Почему компании с этим мирятся? Почему не выгоняют на мороз?
Выскажу гипотезу. Если кратко: некого забирать «с мороза» взамен.
Отчет, который в основе оригинальной статьи, основан на масштабном опросе. За 3,5 года в нем приняло участие 150 000 респондентов из более чем 135 стран. По сути он отражает общие усредненные тенденции по индустрии и в какой‑то степени иллюстрирует известный анекдот про среднюю температуру по больнице.
Одна из задач исследователей — как раз обратить внимание на существующие в индустрии вызовы и зоны для роста (без учета отдельных компаний и стран). Тревожная тенденция — рост доли команд с низкой производительностью по всем ключевым метрикам развертывания.
Теперь по вашим вопросам (Я где‑то мог ошибиться — поправьте, пожалуйста, если заметите неточность.)
Речь идет о метриках DORA — например, Lead time for code changes. Разработчикам задавался вопрос: «В среднем, сколько времени у вас уходит с момента коммита кода до его успешного запуска в production?» (On average, how long does it take you to go from code committed to code successfully running in production?).
Отсчет времени идет именно от коммита, включая все последующие стадии: сборку, все виды автоматизированного и, возможно, ручного тестирования, мерж (если он не является самим коммитом в основную ветку), развертывание на различные окружения и успешный запуск на проде.
Еще задавался вопрос: «В среднем, сколько времени у вас или вашей команды уходит на восстановление сервиса после незапланированного сбоя или нарушения работоспособности?» (On average, how long does it take you or your team to restore service from an unplanned outage or service impairment?).
Данные из отчета (Q1 2024) следующие:
менее чем за час — 11% (этот показатель снизился с 17% в Q3 2020 и остается на уровне около 11% с Q3 2022),
от часа до дня — 29%,
от дня до недели — 19%,
больше недели — 41% (эта доля показывает устойчивый рост).
У менее опытных разработчиков показатели восстановления хуже значительно.
С опытом менее 2 лет:
5% — могут восстановить сервис менее чем за час,
67% — тратят на это более недели.
С опытом более 16 лет:
22% — восстановят за час,
9% — будут возиться две недели.
Также нужно учитывать, что не все сбои одинаковы — не все из них катастрофичны, некоторые могут быть и незначительными.
Еще отчет подчеркивает, что тимлиды играют ключевую роль в улучшении метрик — например, стандартизируют инструменты или обучают новичков. Когда этого не происходит, проблемы носят системный характер, и увольнение специалистов их никак не решит.
Справиться с неуспеваемостью и выгоранием мне помогли трекеры и расчет времени. Все рабочие задачи собраны в электронной таблице. Для каждой из них записываются предполагаемая продолжительность и уже потраченные часы и минуты. Таблица разбита на секции. Внизу есть автоматические вычисляемая сводка по отдельным секциям и по всем задачам в совокупности. Всегда видно текущую успеваемость — например, в среду вечером это может быть −1,5 ч.
В конце недели чрезвычайно полезно проанализировать, где ошибся. Неверная оценка затрат на какие-то задачи наблюдается всегда — видимо, такая погрешность неизбежна. Однако автоматический расчет времени заранее просигналит, когда что-то идет не так, и требуется скорректировать план, чтобы не было завала. Кстати, в этом списке есть и неконкретные пункты — «Мелкие и срочные задачи», а также «Незапланированное взаимодействие».
Когда плану доверяешь и уверен в точности картины, то намного легче — просто очевидно, что обозначенные задачи будут выполнены, причем в срок.
Чтобы это все работало, потребовались трекеры. У меня их семь штук — четыре неизменные и три для меняющихся задач. Все трекеры всегда на виду и переключаются щелчком мыши — очень удобно. Периодически синхронизирую накопившиеся минуты с табличкой. Учет деятельности помог выловить пожирателей времени и сил.
На своем опыте убедился в справедливости изречения: «Что не измеряешь, то не контролируешь».
Всем удачи, творческих свершений и полноценного отдыха!
Так открыть рядом вкладку с инструкциями, запрятанными в docstrings — это обходное решение. Маркетологи Copilot в шоке будут от такой смекалки, если узнают.
Тут на уровне архитектуры то ли недоработка, то ли специально так сделали, чтобы не перегружать нейросеть. Есть же проекты, где десятки и даже сотни связанных файлов. Если LLM начнет собирать всё их содержимое в контекст, то наверняка возникнут проблемы с производительностью.
Здравствуйте! Говоря о бухгалтере, держал в голове растущую озабоченность эффективностью использования средств. Действительно, получилось неудачно. Спасибо, что указали на неточность — подправил.
В облаке Selectel даже за выключенной ВМ закреплены все ресурсы, которые в ней используются. С одной стороны, это дает гарантию доступности ресурсов при включении ВМ, с другой — невозможность их выдать кому‑то еще. Поскольку ресурсы находятся в полном распоряжении клиента, за них взимается оплата.
Обычно autoscaling востребован проектами, которым нужно быстро масштабироваться в случае резкого роста нагрузки. При этом зачастую заранее неизвестны ни время, когда ожидается скачок нагрузки, ни итоговое количество виртуальных машин, необходимых для того, чтобы с ней справиться.
Описанное нами решение действительно в чем‑то схоже. Однако оно также может быть применимо в ситуациях, когда про рост нагрузки всё известно заранее, а какие-то процессы не автоматизированы.
Изначально сервер находится в вашем распоряжении. Вы можете использовать его произвольным образом, в том числе совсем выключить. Ресурсы всё так же закреплены за вами, не могут быть никому переданы, а потому продолжают оплачиваться. Сервер можно и включить в любой момент — он полностью ваш.
Если же сервер заморожен — ресурсы высвобождаются и возвращаются в распоряжение облака. Они могут быть временно выданы кому-то другому, поэтому вы за них не платите. Зато есть какая‑то вероятность, что сервер не сможет запуститься мгновенно, если каких‑то ресурсов не будет в наличии.
Нет‑нет, графические карты замораживаются прекрасно — стоимость их аренды также падает до нуля. Срок заморозки не ограничен — замороженные ресурсы арендной платы не потребляют.
Диск заморозить невозможно — хранящиеся на нем данные нельзя вернуть в распоряжение облака. Стоимость зависит от многих факторов, но ее нельзя назвать высокой — например, 80 руб./мес, за 50 ГБ в СПб. Воспользуйтесь нашим калькулятором цен — все сомнения исчезнут.
Ах, нет же! Всё же наоборот! Никакого «головняка» нет — заморозка и разморозка занимает считаные секунды. Графические карты замораживаются прекрасно. Экономия отнюдь не копеечная — срок заморозки никак не ограничен. Ну, IP‑адрес, действительно не заморозишь — но его аренда и есть «сущие копейки».
Пример Вася и Пети — это тоже в какой-то степени «локальный экстремум».
Проблема Пети — не в тщательности подхода, а в полном отрыве от рынка. Если предположить, что Петя исцелился от бизнесофобии, то в какой-то момент может выясниться, что его продукт выигрывает, а разработка обходится дешевле.
Случай Васи корректен, только если его продукт безальтернативен. Никто не любит терпеть баги. Недостаточное качество может привести к формированию отрицательного имиджа продукта.
Тема неимоверно глубокая. Как будто никак не нащупать правильную точку зрения, поэтому мы перебираем несколько утрированные примеры.
Если смотреть с позиции заказчика, то да. Со стороны же исполнителя всё не так однозначно. Разработчик в процессе оптимизации вынужден докапываться до тонкостей. Объем его профессиональных знаний и навыков от этого только выигрывает.
С такой стороны даже ненужную оптимизацию можно рассматривать как маленькую инвестицию в образование. Окупит ли она себя? Убежден, что да. Даже в том случае, если напрямую приобретенный опыт не пригодится. Кстати, и в статье эта мысль промелькнула.
Соглашусь, тема поднималась не раз. Однако актуальности она своей не потеряла. Мощности вырасли на порядки. Но и сложность задач тоже: ML, рендеринг, обработка лавинообразно растущих данных. сложные распределенные системы… Полувековой спор про оптимизацию так и не закончился.
Соглашусь и дополню. С оговоркой, что, конечно, российские компании (Яндекс, Сбер, Тинькофф) вообще никак в исследовании не участвовали, а «средняя температура по больнице» скрывает очень многое. Примечательно, что авторы и сами подчеркивают: нет единого рецепта.
Как мне показалось, ваши наблюдения где‑то пересекаются и с самим исследованием, и с выводами оригинальной статьи.
Зависимость от команды и управления
Исследователи прямо говорят об этом: «Несомненно, это зависит от обстоятельств, организации, характера работы, выполняемых задач и самого человека». Они хорошо проехались и по начальникам, которые предпочитают стоять над душой: «Для успешной децентрализации (коей является удаленка) компания должна быть особенно хорошо управляема. Чем слабее менеджмент, тем сильнее стремление вернуть всех в офис», — тут не дословно, а скомпилированная мысль.
Квоты и гибридный формат
Упомянутая квота в Сбере (70% в офисе) — яркий пример того, к чему, согласно прогнозам, и движется большинство компаний. Почти все руководители — за гибрид. Так что политика Сбера — не столько отрицание удаленки, сколько реализация самого популярного гибридного сценария.
Выбор сотрудников и «утечка мозгов»
Пример про знакомых, уехавших в теплые страны, — тоже прямое подтверждение одного из главных выводов статьи. Авторы прогнозируют: «Сотрудники будут тяготеть к фирмам с более гибкой политикой». Это не что иное, как колоссальное конкурентное преимущество в борьбе за таланты — просто не всем компаниям оно требуется.
Специфика (безопасность, госсектор)
Требования к безопасности и работе из РФ — такой пласт вопросов, который американское исследование, конечно, не охватывает. Я лично тут воздержусь от комментариев. Вообще то, как люди решают проблемы с формальными запретами — невероятно интересная, но уже совсем другая тема. Я даже не знаю, есть ли такое исследование. Было бы интересно с ним познакомиться.
Главная ценность этой статьи 23-го года — в долгосрочных прогнозах и анализе фундаментальных трендов, которые не так быстро меняются. Опрос, на который ссылаются авторы, просил руководителей заглянуть на пять лет вперед, до 2028 года. То есть анализируется не сиюминутная ситуация, а долгосрочные ожидания топ‑менеджеров.
Исследование выделяет несколько причин, почему удаленная работа останется надолго, и они носят не временный, а структурный характер.
Вынужденный эксперимент. Миллионы компаний и сотрудников были вынуждены попробовать удаленку — их желания никто не спрашивал. Опыт для многих оказался лучше, чем ожидалось — отношение к такому формату изменилось навсегда.
Инвестиции в инфраструктуру. И сотрудники, и компании вложили значительные средства и время в обустройство домашних офисов и разработку ПО. В среднем каждый работник потратил на это 15 часов и $561 — но это только меры в период срочности.
Сдвиг отношения. Работа из дома часто воспринималась как «отлынивание». Массовый переход изменил восприятие: две трети опрошенных отметили, что отношение к удаленке среди их знакомых улучшилось.
Инновации. Резкий рост рынка удвоил число патентов на технологии, которые поддерживают удаленку: видеоконференции, средства для совместной работы и т. д. Технологический прогресс в этой области «раскрутился» и уже сам влияет на рынок.
Конкретные цифры (например, 28% работающих из дома) со времени выхода оригинальной статьи могут колебаться, но выводы и прогнозы того, что удаленка надолго, остаются актуальными.
Трудно не согласиться. Экономия времени на дорогу — одно из главных преимуществ удаленки.
Цифра в 8% — это усредненный результат. Участникам задавали прямой вопрос: «На какое снижение зарплаты вы готовы пойти ради возможности работать из дома 2−3 дня в неделю?» Это субъективная оценка самими опрашиваемыми, а не расчет, основанный на времени в пути.
В исследовании есть даже цифры и повыше. Среднее время до работы и обратно — 54 минуты в день. Выяснилось, что оно напрямую зависит от уровня дохода:
те, у кого выходит менее $30 000 в год, тратили на дорогу в одну сторону в среднем менее 22 минут.
кто зарабатывает $150 000 до $250 000 — уже около 44 минут в одну сторону.
Исследование напрямую не учитывает время на «подготовку к работе». Правильнее было бы его тоже считать частью тех самых выгод и суммировать в общей оценке.
Автор оригинальной статьи пишет об IT с тех пор, как CP/M стала самой популярной операционной системой. Мне кажется, если просто сказать «журналист» — на ум может прийти неверная ассоциация.
Кроме того, автор оригинальной статьи ничего не добавил к отчету State of CI/CD Report. Если кажется, что какие‑то высказывания в отчете неверны, то правильнее обратить критику на Continuous Delivery Foundation, а также на организаторов cdCon и Open Source Summit North America за то, что тех пригласили.
Речь не о том, что «самое простое действие от нажатия enter при команде git push» стало дольше. Ключевая метрика, о которой говорится, — Lead time for code changes — измеряет время от момента коммита кода до его успешного запуска в production. Сюда входит вся цепочка: сборка, тестирование, развертывание и т. д., а не только git push.
Для многих (41% в Q1 2024) доставка изменений действительно превращается в «квесты» на месяц. Доля таких команд выросла (в Q3 2020 их было 34%). В то же время сегмент наиболее быстрых команд, у которых этот процесс занимает менее одного дня, остается относительно стабильным (14% в Q1 2024).
Смысл статьи (и отчета, на котором она основана) — показать актуальное состояние DevOps, оценить эффективность доставки ПО, а также выявить факторы, которые на всё влияют.
Отчет предполагает, что одна из причин наблюдаемых трендов — рост сложности проектов, который нивелирует некоторые выгоды от внедрения DevOps. Я не возьмусь делать самостоятельные выводы, так это или нет. Мне показались интересными и само исследование, и оригинальная статья, которая является его обзором.
Отчасти соглашусь, но своего мнения высказывать не стану, так как не считаю себя вправе спорить по этому вопросу. Поскольку тема мне очень интересна, я постарался разобраться в отчете (насколько смог) и попробую ответить как бы от имени автора оригинальной статьи. Замечу, что не полностью разделяю его взгляды, да и он сам не выходит за рамки выводов State of CI/CD Report, поэтому и я буду отталкиваться от того же отчета.
Необходимость выкатить только что написанный код в продакшн
Не каждый коммит предназначен для немедленного развертывания. Отчет же, как я понял, стремится к тому, чтобы команды имели возможность безопасно и быстро это делать при необходимости.
Lead time for code changes
Высокие показатели здесь не обязательно означают, что все коммиты идут в прод немедленно, а процесс отлажен и быстр. Хотфиксы, требуют скорости, а эффективные CI/CD пайплайны этому способствуют. Отчет показал, что только 14% разработчиков могут задеплоить код за день, 41% же вообще тратят на это месяц.
Скорость деплоя и ее неоднозначность
В отчете речь идет про Deployment frequency — одну из ключевых метрик DORA. Она измеряет частоту развертывается кода (стр. 21 отчета). При этом метрика никак не оценивает сложность каждого конкретного развертывания (будь то смена ID образа или создание нового пайплайна). Она отражает общую способность команды регулярно поставлять работающий код.
«Пилить новые пайплайны/манифесты»
Сложность подготовки к развертыванию скорее отразится на Lead time for code changes — время, затраченное до того, как изменение будет готово к деплою и запущено. Цель — сделать даже сложные развертывания более управляемыми и менее трудоемкими (за счет автоматизации и стандартизации).
Отчет не смешивает maintenance и development с точки зрения самих задач. Однако результативность процессов доставки ПО действительно оценивается в целом — тут не поспоришь.
Восстановление сервиса в течение недели и SLA/RTO
Вы совершенно правы, что SLA и RTO (Recovery Time Objective) — это бизнес-параметры, которые и определяют допустимое время простоя. Метрика DORA Time to restore service как раз измеряет, сколько времени уходит на восстановление сервиса после незапланированного сбоя (стр. 22).
С точки зрения DORA, это показатель операционной эффективности команды. Даже если SLA позволяет сервису «валяться дольше», способность быстро восстанавливаться — это признак зрелости процессов, качества архитектуры и экспертизы команды.
Действительно, если SLA не нарушен, формально «нет проблемы» с точки зрения контракта. Но с точки зрения конкурентоспособности, удовлетворенности клиентов и репутации бизнеса, длительные простои редко бывают желательны, даже если укладываются в SLA. Исследование стремится улучшить именно фактическую способность быстрого восстановления.
Кризис в качестве управления проектами и другие факторы
Ваше наблюдение о том, что описанные проблемы могут указывать на более глубокие системные недочеты в управлении, перекликается с некоторыми выводами отчета:
подчеркивается «важная роль, которую организации и руководители команд играют в направлении своих команд к более высокой производительности»;
указывается на необходимость «обеспечить, чтобы новые разработчики были лучше знакомы с DevOps в целом, а также с практиками, используемыми в организации»;
отмечается, что некоторые организации не внедряют и не стандартизируют лучшие практики, что приводит к зависимости производительности от индивидуального опыта разработчиков — это тоже можно рассматривать как недостатки в управлении.
Я о том же примерно написал, что не все сбои одинаковы. Согласен с вами — степень тяжести можно оценивать по времени, нужном для восстановления сервиса. И говорим мы, конечно, чисто о технической стороне (без учета репутационных и прочих сопутствующих потерь).
Почему компании с этим мирятся? Почему не выгоняют на мороз?
Выскажу гипотезу. Если кратко: некого забирать «с мороза» взамен.
Отчет, который в основе оригинальной статьи, основан на масштабном опросе. За 3,5 года в нем приняло участие 150 000 респондентов из более чем 135 стран. По сути он отражает общие усредненные тенденции по индустрии и в какой‑то степени иллюстрирует известный анекдот про среднюю температуру по больнице.
Одна из задач исследователей — как раз обратить внимание на существующие в индустрии вызовы и зоны для роста (без учета отдельных компаний и стран). Тревожная тенденция — рост доли команд с низкой производительностью по всем ключевым метрикам развертывания.
Теперь по вашим вопросам (Я где‑то мог ошибиться — поправьте, пожалуйста, если заметите неточность.)
Речь идет о метриках DORA — например, Lead time for code changes. Разработчикам задавался вопрос: «В среднем, сколько времени у вас уходит с момента коммита кода до его успешного запуска в production?» (On average, how long does it take you to go from code committed to code successfully running in production?).
Отсчет времени идет именно от коммита, включая все последующие стадии: сборку, все виды автоматизированного и, возможно, ручного тестирования, мерж (если он не является самим коммитом в основную ветку), развертывание на различные окружения и успешный запуск на проде.
Еще задавался вопрос: «В среднем, сколько времени у вас или вашей команды уходит на восстановление сервиса после незапланированного сбоя или нарушения работоспособности?» (On average, how long does it take you or your team to restore service from an unplanned outage or service impairment?).
Данные из отчета (Q1 2024) следующие:
менее чем за час — 11% (этот показатель снизился с 17% в Q3 2020 и остается на уровне около 11% с Q3 2022),
от часа до дня — 29%,
от дня до недели — 19%,
больше недели — 41% (эта доля показывает устойчивый рост).
У менее опытных разработчиков показатели восстановления хуже значительно.
С опытом менее 2 лет:
5% — могут восстановить сервис менее чем за час,
67% — тратят на это более недели.
С опытом более 16 лет:
22% — восстановят за час,
9% — будут возиться две недели.
Также нужно учитывать, что не все сбои одинаковы — не все из них катастрофичны, некоторые могут быть и незначительными.
Еще отчет подчеркивает, что тимлиды играют ключевую роль в улучшении метрик — например, стандартизируют инструменты или обучают новичков. Когда этого не происходит, проблемы носят системный характер, и увольнение специалистов их никак не решит.
Добавлю свои пять копеек.
Справиться с неуспеваемостью и выгоранием мне помогли трекеры и расчет времени. Все рабочие задачи собраны в электронной таблице. Для каждой из них записываются предполагаемая продолжительность и уже потраченные часы и минуты. Таблица разбита на секции. Внизу есть автоматические вычисляемая сводка по отдельным секциям и по всем задачам в совокупности. Всегда видно текущую успеваемость — например, в среду вечером это может быть −1,5 ч.
В конце недели чрезвычайно полезно проанализировать, где ошибся. Неверная оценка затрат на какие-то задачи наблюдается всегда — видимо, такая погрешность неизбежна. Однако автоматический расчет времени заранее просигналит, когда что-то идет не так, и требуется скорректировать план, чтобы не было завала. Кстати, в этом списке есть и неконкретные пункты — «Мелкие и срочные задачи», а также «Незапланированное взаимодействие».
Когда плану доверяешь и уверен в точности картины, то намного легче — просто очевидно, что обозначенные задачи будут выполнены, причем в срок.
Чтобы это все работало, потребовались трекеры. У меня их семь штук — четыре неизменные и три для меняющихся задач. Все трекеры всегда на виду и переключаются щелчком мыши — очень удобно. Периодически синхронизирую накопившиеся минуты с табличкой. Учет деятельности помог выловить пожирателей времени и сил.
На своем опыте убедился в справедливости изречения: «Что не измеряешь, то не контролируешь».
Всем удачи, творческих свершений и полноценного отдыха!
Так открыть рядом вкладку с инструкциями, запрятанными в docstrings — это обходное решение. Маркетологи Copilot в шоке будут от такой смекалки, если узнают.
Тут на уровне архитектуры то ли недоработка, то ли специально так сделали, чтобы не перегружать нейросеть. Есть же проекты, где десятки и даже сотни связанных файлов. Если LLM начнет собирать всё их содержимое в контекст, то наверняка возникнут проблемы с производительностью.
Здравствуйте! Говоря о бухгалтере, держал в голове растущую озабоченность эффективностью использования средств. Действительно, получилось неудачно. Спасибо, что указали на неточность — подправил.
В облаке Selectel даже за выключенной ВМ закреплены все ресурсы, которые в ней используются. С одной стороны, это дает гарантию доступности ресурсов при включении ВМ, с другой — невозможность их выдать кому‑то еще. Поскольку ресурсы находятся в полном распоряжении клиента, за них взимается оплата.
Разные провайдеры могут применять в чем‑то отличающиеся подходы и придерживаться своей терминологии. К примеру, у Amazon AWS при остановке ВМ высвобождаются все ресурсы, кроме EBS и IP‑адресов. При этом они в явном виде пишут в документации, что при перезапуске остановленного инстанса свободных ресурсов может быть недостаточно и он не запустится.
Фактически «остановка ВМ в AWS» действует как «заморозка ВМ в Selectel».
Обычно autoscaling востребован проектами, которым нужно быстро масштабироваться в случае резкого роста нагрузки. При этом зачастую заранее неизвестны ни время, когда ожидается скачок нагрузки, ни итоговое количество виртуальных машин, необходимых для того, чтобы с ней справиться.
Описанное нами решение действительно в чем‑то схоже. Однако оно также может быть применимо в ситуациях, когда про рост нагрузки всё известно заранее, а какие-то процессы не автоматизированы.
Ошибки здесь нет, поясню чуть подробнее.
Изначально сервер находится в вашем распоряжении. Вы можете использовать его произвольным образом, в том числе совсем выключить. Ресурсы всё так же закреплены за вами, не могут быть никому переданы, а потому продолжают оплачиваться. Сервер можно и включить в любой момент — он полностью ваш.
Если же сервер заморожен — ресурсы высвобождаются и возвращаются в распоряжение облака. Они могут быть временно выданы кому-то другому, поэтому вы за них не платите. Зато есть какая‑то вероятность, что сервер не сможет запуститься мгновенно, если каких‑то ресурсов не будет в наличии.
Нет‑нет, графические карты замораживаются прекрасно — стоимость их аренды также падает до нуля. Срок заморозки не ограничен — замороженные ресурсы арендной платы не потребляют.
Диск заморозить невозможно — хранящиеся на нем данные нельзя вернуть в распоряжение облака. Стоимость зависит от многих факторов, но ее нельзя назвать высокой — например, 80 руб./мес, за 50 ГБ в СПб. Воспользуйтесь нашим калькулятором цен — все сомнения исчезнут.
Ах, нет же! Всё же наоборот! Никакого «головняка» нет — заморозка и разморозка занимает считаные секунды. Графические карты замораживаются прекрасно. Экономия отнюдь не копеечная — срок заморозки никак не ограничен. Ну, IP‑адрес, действительно не заморозишь — но его аренда и есть «сущие копейки».
Пример Вася и Пети — это тоже в какой-то степени «локальный экстремум».
Проблема Пети — не в тщательности подхода, а в полном отрыве от рынка. Если предположить, что Петя исцелился от бизнесофобии, то в какой-то момент может выясниться, что его продукт выигрывает, а разработка обходится дешевле.
Случай Васи корректен, только если его продукт безальтернативен. Никто не любит терпеть баги. Недостаточное качество может привести к формированию отрицательного имиджа продукта.
Тема неимоверно глубокая. Как будто никак не нащупать правильную точку зрения, поэтому мы перебираем несколько утрированные примеры.
Если смотреть с позиции заказчика, то да. Со стороны же исполнителя всё не так однозначно. Разработчик в процессе оптимизации вынужден докапываться до тонкостей. Объем его профессиональных знаний и навыков от этого только выигрывает.
С такой стороны даже ненужную оптимизацию можно рассматривать как маленькую инвестицию в образование. Окупит ли она себя? Убежден, что да. Даже в том случае, если напрямую приобретенный опыт не пригодится. Кстати, и в статье эта мысль промелькнула.
Соглашусь, тема поднималась не раз. Однако актуальности она своей не потеряла. Мощности вырасли на порядки. Но и сложность задач тоже: ML, рендеринг, обработка лавинообразно растущих данных. сложные распределенные системы… Полувековой спор про оптимизацию так и не закончился.
Да. Невосполнимая утрата.