Ебеда в производстве: особенности вычисления по данным МСФО-отчетности

Алексей Куличенко, ПАО «СЕВЕРСТАЛЬ», «Как удвоить EBITDA без бюджетного процесса и EBITDA в KPI отдельных предприятий»

Когда начали проект по трансформации компании?

Формально мы начали жить в рамках новой стратегии с 2018 года, фактически к середине 2018-го мы окончательно сформулировали ее, объявили и приступили к реализации. Мы хотим трансформировать «Северсталь», по сути, в другую компанию с точки зрения внутренней культуры и стратегических приоритетов. С моей точки зрения, это беспрецедентный уровень изменений для нашей компании.

Как пришла идея о трансформации?

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

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

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

С чего начали разработку стратегии?

Мы задали себе вопрос: как мы можем ответить на все вызовы, с которыми сталкиваемся? Как мы должны пересмотреть в связи с этим стратегию?

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

Какие области затронула трансформация?

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

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

Это, наверное, на сегодняшний день основная, самая важная и сложная в реализации составляющая программы трансформации.

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

Третий блок называется «Радикальные инновации и инновации бизнес-модели». Мы видим, что происходит много изменений вокруг нас, начиная с IT-технологий и заканчивая появлением новых материалов, технологий производства, бизнес-моделей, новых процессов на их основе и т. д.

Мы понимаем, что в силу масштаба компании мы достаточно «неповоротливы», мы поздно узнаем об инновациях. Наша задача — узнавать о них как можно раньше и иметь возможность быстро встроить новые механизмы в свою бизнес-модель.

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

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

Как действовали после того, как определились с отраслями трансформации?

Разработали программы по каждому блоку с конкретными действиями и мероприятиями.

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

В чем заключалась работа по трансформации цепочки поставок?

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

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

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

Мы поняли, что нужно продлять sales&operation планирование до дистрибьюторской сети. Теперь в этой цепочке появилась и клиентская составляющая, на этапе логистики появился дополнительный клиентский сервис.

Работники supply chain используют гибкие планы, которые ежедневно обновляют, пересчитывают все поступившие заказы и выдают задачи для производства.

Пересмотрели структуру компании в связи с трансформацией?

С точки зрения управленческого учета — кардинально. Раньше мы использовали традиционную систему продуктовых дивизионов: «Сталь», «Уголь» и т. д.

Теперь компания разделилась на две части: upstream и downstream. Upstream — это монопродукт, базовая жидкая сталь, в этом блоке пока нет никакой клиентской специфики. Как только сталь начинает превращаться в индивидуальные продукты для различных отраслей, это уже downstream. Именно в downstream аккумулируется вся коммерческая работа.

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

Upstream и downstream, можно сказать, функционально «разрезают» компанию посередине, одна и та же бизнес-единица — сталеплавильное производство, относится и к upstream, и к downstream. Это совершенно другой взгляд на компанию, и он требовал в том числе полного пересмотра целеполагания и оценки результатов.

Как изменили систему целеполагания?

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

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

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

Надо видеть картину в целом.

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

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

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

Как компания чувствует себя без бюджета?

Прекрасно. Мы используем много элементов beyond budgeting. Но в целом это скорее наш собственный подход, который мы разработали и скомбинировали.

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

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

Что помогает контролировать достижение поставленных целей без бюджета?

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

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

Как коллектив принял отказ от бюджетов и прибыли в KPI?

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

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

Пересматриваете стратегию в процессе реализации?

Главная цель по EBITDA у нас не плавающая, она остается. А вот дополнение стратегии и шаги, которые помогают достичь цели, меняются. Какие-то проекты перестают быть актуальными, как только мы узнаем что-то новое. Важность других, наоборот, растет. Например, если смотреть на 2018 год, на старт, мы понимали, что работа над цепочкой поставок клиенту — блоком supply chain — важна, но не понимали на тот момент — насколько.

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

Как в «Северстали» управляют проектами?

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

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

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

Работа финансовой службы изменилась в связи с трансформацией?

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

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

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

Численность финансовой службы изменилась с начала трансформации?

Незначительно. До начала трансформации мы уже были одними из лидеров по эффективности финансовой службы: при общей численности 50 тыс. сотрудников у нас было 160 контролеров, ожидается, что будет 170, общая численность финансовой функции — около 550. То есть финансовая служба составляет около 1 процента от численности компании.

Финансовая служба централизованна?

Функционально да. Территориально — у нас есть Ярославский центр обслуживания, в котором аккумулируются обслуживающие функции, но контролеры разбросаны по тем предприятиям, которые курируют.

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

На Ваш взгляд, Agile-формат и строгие регламенты могут существовать вместе?

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

Какой эффект от трансформации уже ощутили?

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

В этом году мы пока понимаем достижение поставленных целей примерно на 80 процентов, это хороший результат. Первый год реализации новой стратегии стал прорывным. Но удержать этот эффект, превратить его из подвига в закономерность — это определенный тест на зрелость, который нам предстоит пройти в 2019 году.

Что такое EBITDA и зачем она нужна — Деньги на vc.ru

Человек устроен таким образом, что всё время что-нибудь сравнивает: Месси с Роналду, лето с зимой, свой с соседским. Предприниматели не исключение — вечно меряются тем, чья компания круче.

2996 просмотров

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

Поэтому компании из одной ниши сравниваются друг с другом по EBITDA. Что это такое и зачем нужно — разберем в нашей статье👇

Что такое EBITDA

EBITDA (Earnings before interest, taxes, depreciation and amortization) — прибыль до вычета процентов, налогов, износа и амортизации. Она показывает финансовый результат в ходе основной работы компании — операционной деятельности. Рассчитать её можно по следующей формуле:

EBITDA = выручка – постоянные расходы – переменные расходы

В чем ее смысл

Действительно: только научились считать валовую прибыль и вычислять по ней рентабельность, как вдруг – на тебе – EBITDA! О чем это?

Приведем пример:

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

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

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

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

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

Не унываем! Меняем угол зрения и устраняем неравенство, не связанное с менеджментом. Очевидно, что при организации производственного процесса очень трудно отрегулировать все показатели сразу, а уж налоговый режим не удаётся оптимизировать годами. Поэтому я предложил ему сравнить только операционные доходы и расходы. И вот что получилось:

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

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

Что это значит для предпринимателя? Если вы уже ведете управленческий учет, размер EBITDA покажет вам, достаточно ли у вас ресурса, чтобы содержать активы, преодолевать налоговую нагрузку и тянуть проценты по кредиту. А ключевая задача для повышения эффективности работы компании — заставить EBITDA расти, а показатели после нее — сокращаться. Это и будет потихоньку делать бизнес прибыльнее.

Вывод

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

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

Также EBITDA позволяет оценить, хватит ли ресурса для покрытия процентов по кредитам и займам, покрытия амортизации и налоговой нагрузки.

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

Ваш Финвед

9 техник исправления ошибок в продакшене

Качество программного обеспечения

Фотолия

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

К

• Джордж Лоутон

Опубликовано: 18 фев 2021

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

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

Команды разработчиков программного обеспечения могут использовать следующие девять способов исправления ошибок в рабочей среде:

1. Установить стандартизированный процесс.
2. Составьте планы по быстрому устранению дефектов.
3. Практика тайм-менеджмента.
4. Внедрение контрольных показателей.
5. Установить приоритет тестового кода.
6. Выполнить хаос-инженерию.
7. Двигайся быстро и ломай вещи.
8. Примите критически важный менталитет.
9. Созревание продукта.

Установить стандартизированный процесс

Важно установить стандартизированный процесс устранения ошибок.

«Исчезновение дефектов — это печальная реальность разработки программного обеспечения, — сказал Кейси Гордон, директор Agile-инжиниринга в Liberty Mutual Insurance. Несмотря на все усилия по устранению дефектов до того, как они попадут в руки клиентов, неизбежно возникают производственные проблемы. Персонал Гордона полагается на упреждающий мониторинг, инструменты наблюдения и отзывы клиентов для оповещения о таких дефектах.

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

«Мы узнали, что чрезмерная осторожность и применение устаревших подходов к управлению выпуском приводит только к увеличению размера партии, увеличению среднего времени восстановления и повышению риска», — сказал Гордон. Используя методы DevOps, разработчики Liberty Mutual внедряют в производство более мелкие и целенаправленные выпуски. Эти инженеры также разделили программные компоненты на слабосвязанные микросервисы. Микросервисы позволяют им устранять проблемы с помощью незначительных изменений кода и меньшего количества процессов, чем это потребовалось бы для монолитной архитектуры.

План быстрого устранения дефектов

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

«Хотя мы думаем, что должны делать все, что в наших силах, чтобы избежать ошибок в рабочей среде, вы все равно должны планировать, когда, а не если ошибка всплывет [там]», — сказал Йозеф Раддинг, инженер-разработчик программного обеспечения в Amazon, который также предоставляет Консультации по DevOps через Shuttl.io. Разработчики могут обеспечить более быстрое решение проблемы, проактивно работая над узкими местами, которые могут замедлить исправление.

Во-первых, сфокусируйтесь на упрощении локального запуска кода и его зависимостей с помощью 12-факторной методологии приложений, рекомендует Рэддинг. 12 факторов относятся к следующему:

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

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

Затем сосредоточьтесь на мониторинге и ведении журналов, чтобы быстро выявлять проблемы. Такие технологии, как функциональные флаги, которые являются переключателями для включения и выключения частей базы кода, могут легко и быстро остановить проблемные области — всего за 200 миллисекунд. «На самом деле мы постоянно сохраняем некоторые флаги функций вокруг особенно неприятного кода и интеграций, чтобы дать нам аварийный переключатель на случай, если что-то пойдет не так в любое время», — сказал Раддинг.

Он также рекомендует отменить изменения, а не откатывать их. Radding использует команду git revert для отмены определенных коммитов и добавляет новый коммит, удаляющий изменения в старом коммите. Этот метод гарантирует, что другие изменения останутся, когда разработчик удалит проблемный код.

Практика тайм-менеджмента

Исправление ошибок происходит быстрее и менее разрушительно для производства, если у команды есть хорошо спланированный подход. Есть несколько путей, по которым можно следовать, каждый со своими плюсами и минусами, — сказал Фил Криппен, генеральный директор John Adams IT, консалтинговой компании по ИТ-услугам.

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

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

Внедрение контрольных показателей

Команды разработчиков программного обеспечения должны использовать эталонные тесты, чтобы оценить, сколько ошибок команда может исправить за месяц. Например, в США средний программист может исправить от 9 до 10 ошибок в месяц, сказал Криппен. За это время опытный программист может исправить до 20 ошибок. Имея в виду эти средние значения, ИТ-руководители могут оценить, сколько ошибок может исправить команда.

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

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

Код проверки приоритета

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

«Сначала разработка может замедлиться, когда вы начнете писать тесты для существующей функциональности, но качество повысится», — сказал Шейн Шерман, генеральный директор TechLoris, службы ИТ-консалтинга.

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

Выполнить хаос-инженерию

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

«Инженерия хаоса — это способ проверки того, что вся система делает то, что вы от нее хотите, а код — это лишь часть комплекса», — сказал Маниш Мистри, технический директор Infostretch, консалтинговой компании по цифровым технологиям. Для эффективного тестирования система должна быть запущена в производственной среде. В конце концов, только в производственной среде команда может работать с такими факторами, как состояние, входные данные и поведение внешних систем.

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

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

Двигайся быстро и ломай вещи

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

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

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

По мере своего роста Facebook воплощал в себе принцип «двигайся быстро и ломай вещи», который помог компании доминировать в пространстве социальных сетей. «Учитывая, что Facebook предлагает бесплатный продукт, доставляемый через Интернет, ошибка в производственном коде не была бедствием», — сказал Уэйд-Стейн.

Однако этот подход работает не всегда. Частые ошибки могут раздражать клиентов и подтолкнуть их к чему-то другому. Facebook отказался от девиза в 2014 году.

Примите критически важный менталитет

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

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

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

Созревание продукта, затем его стабилизация

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

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

«После того, как вы достигнете соответствия продукта рынку, вы должны сосредоточиться на стабилизации вашего продукта», — сказал он.

Следующие шаги

Исправление критической ошибки в ИТ требует координации и терпения

Копните глубже в жизненный цикл разработки программного обеспечения

• Какие сведения включать в отчет о дефектах программного обеспечения

  Автор: Эми Райхерт

• тестирование программного обеспечения

  Автор: Кинза Ясар

• Мышление, ориентированное на скорость, а не на качество, приводит к пробелам в тестировании программного обеспечения

  Автор: Стефани Глен

• Как отслеживать и измерять технический долг

  Автор: Стивен Бигелоу

Облачные вычисления

• Обновления Dell Apex поддерживают корпоративные переходы «из облака в землю»

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

• Подготовьтесь к сертификации специалиста по безопасности Azure.

  Готовы ли вы улучшить свое резюме или продолжить карьеру в сфере облачных вычислений? Ознакомьтесь с этим руководством по подготовке к экзамену AZ-500 …

• Dell переводит периферийное развертывание с передовой на NativeEdge

  В Dell Tech World поставщик стремится упростить развертывание и управление тысячами периферийных устройств в разных местах, как …

Архитектура приложения

• Здравый взгляд на масштабируемость архитектуры программного обеспечения

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

• 4 навыка корпоративного архитектора, которые никогда не следует упускать из виду

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

• Falcor против GraphQL: важные различия

  Хотя оба по существу представляют собой два подхода к одной и той же конечной цели, между GraphQL и Falcor есть некоторые ключевые различия…

ITОперации

• Управляйте ИТ-инфраструктурой с помощью многопользовательских функций NSX

  VMware NSX теперь поддерживает мультитенантность, что может помочь администраторам управлять сложными ИТ-средами. Узнайте, что нового и начните…

• ИИ и автоматизация в центре внимания AnsibleFest 2023

  На фоне ажиотажа вокруг возможностей, открываемых искусственным интеллектом и автоматизацией, эксперты Red Hat Summit и AnsibleFest 2023 подчеркнули …

• Автоматизация модернизации: выводы Red Hat Summit 2023

  Узнайте мнение отраслевого аналитика об основных анонсах Red Hat Summit и AnsibleFest в этом году, а также о том, как развивались . ..

TheServerSide.com

• 5 примеров лидера слуг Scrum

  Термин «лидер-слуга» был удален из Руководства по Scrum 2020, но это не значит, что он не важен. Вот пять примеров…

• Как решить проблемы с производительностью Python

  Python — отличный язык для решения математических и научных задач непрограммистами, даже если такая оптимизация влияет на …

• Скрам против водопада: в чем разница?

  Большинство организаций выбирают между методологиями Waterfall и Agile, что часто означает сравнение Scrum и Waterfall. Вот…

ПоискAWS

• AWS Control Tower стремится упростить управление несколькими учетными записями

  Многие организации изо всех сил пытаются управлять своей огромной коллекцией учетных записей AWS, но Control Tower может помочь. Сервис автоматизирует …

• Разбираем модель ценообразования Amazon EKS

  В модели ценообразования Amazon EKS есть несколько важных переменных. Покопайтесь в цифрах, чтобы убедиться, что вы развернули службу…

• Сравните EKS и самоуправляемый Kubernetes на AWS Пользователи

  AWS сталкиваются с выбором при развертывании Kubernetes: запустить его самостоятельно на EC2 или позволить Amazon выполнить тяжелую работу с помощью EKS. См…

Ошибка в производственной среде: то, о чем вы не знаете, может и навредит вам

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

Проблемы запуска с ошибками в коде

Простои программного обеспечения приводят к потере доходов и репутации. На самом деле, аналитики Gartner подсчитали, что средняя стоимость простоя составляет 5600 долларов в минуту — это намного больше 300 000 долларов в час. Чтобы представить реальный пример того, как это выглядит, в ноябре 2018 года в Microsoft Azure произошел серьезный сбой, вызванный проблемами, появившимися как часть обновления кода, продолжавшегося 14 часов и затрагивающего клиентов по всей Европе и за ее пределами. С переходом от устаревших систем к микросредам в облаке сбои и простои представляют собой растущую и серьезную проблему.

Спонсорство доступно

По мере того, как компании переходят на модели DevOps и CI/CD, чтобы двигаться быстрее и быстрее предоставлять обновления приложений, разработчики программного обеспечения постоянно выпускают новые функции и часто выпускают обновления кода так же быстро, как они пишутся. Классические шестимесячные сроки разработки, обеспечения качества (QA) и бета-тестирования были сжаты до нескольких дней, а иногда и часов. Прошли те времена, когда команды могли проводить бета-тестирование с клиентами в течение продолжительных периодов, чтобы отмечать ошибки в режиме реального времени.

С современными инструментами проверки качества разработчики не знают, как новая версия программного обеспечения будет работать в производственной среде и будет ли она вообще работать в производственной среде. Примером этой проблемы является ошибка Cloudbleed: в феврале 2017 года простая ошибка кода в обновлении программного обеспечения от поставщика средств безопасности Cloudflare привела к серьезной уязвимости, обнаруженной исследователем Google несколько месяцев спустя.

Недостатки могут впоследствии привести к серьезным проблемам с безопасностью, в дополнение к упомянутым выше немедленным последствиям. Heartbleed, уязвимость, возникшая в 2014 году и возникшая из-за ошибки программирования в библиотеке OpenSSL, оставила большое количество закрытых ключей и конфиденциальной информации в Интернете, что сделало возможным кражу, которая в противном случае была бы защищена шифрованием SSL/TLS.

Стандартного тестирования QA недостаточно: тестируйте с использованием производственного трафика

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

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

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

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

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

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

Стоимость также остается проблемой. Если вы используете новую версию с 10 % клиентов, а сбой стоит более 300 000 долларов в час, то сбой, затрагивающий 10 % пользователей, потенциально может по-прежнему стоить более 30 000 долларов в час. Влияние, конечно, уменьшается, но все равно остается значительным, не считая неуверенности в том, когда нужно откатиться.

Взгляд в будущее

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