Неопределенность рабочего состояния
Почему «нельзя легко изменить текущее стабильное рабочее состояние»? Это связано с тем, что во многих случаях трудно быть абсолютно уверенным в том, является ли текущее рабочее состояние системы прочным, как скала, или это просто хрупкий баланс.
При внесении необходимых изменений, будучи инициатором изменения, при построении содержания изменения с благоговением, каким принципам следует следовать, чтобы более эффективно контролировать риски изменения и сделать изменение более непринужденным?
При внесении изменений рекомендуется учитывать следующие восемь принципов построения:
Принцип 1: Описываемый
Интегрируйте комментарии к коду, документы запроса на изменение, точки изменения, анализ воздействия, руководство по внедрению изменения и т. д., чтобы четко описать содержание изменения, чем больше измерений, тем шире и глубже диапазон мышления и меньше вероятность ошибок. Если изменение не может быть четко описано, оно эквивалентно метафизике.
Принцип 2: Допускается шкала серого
Содержимое изменений выпускается в оттенках серого, что позволяет быстро проверить небольшой масштаб и незначительное влияние, тем самым создавая лучший ритм изменений и больше места для ошибок.
Принцип 3: наблюдаемый
Создавайте четкие и конкретные наблюдения и показатели для каждого изменения и одновременно проверяйте, эффективны ли основные показатели наблюдения измененной системы. Убедитесь, что после завершения изменения эти индикаторы могут быстро оценить эффективность выпуска изменения и влияние изменения на общую производительность системы, чтобы своевременно вносить коррективы и оптимизации, а также обеспечивать доступность и стабильность системы.
Принцип 4: Возможность отката
Изменения можно быстро и полностью откатить, а скорость отката можно ускорить за счет настройки функциональных переключателей, развертывания контейнеров и т. д. Помимо сосредоточения внимания на возможности отката отдельных изменений, нам также необходимо обратить внимание на возможность отката отдельных изменений. сопутствующие изменения.
Принцип 5: Совместимость
Изменения должны учитывать все виды совместимости, такие как совместимость между операционной системой и браузером, совместимость между версиями зависимых компонентов, совместимость формата данных, совместимость набора символов, совместимость интерфейса, совместимость протокола и т. д., чтобы избежать проблем совместимости после изменение вводится в производство.
Принцип 6: Независимость
Старайтесь, чтобы изменения были как можно более независимыми, и стремитесь уменьшить степень сцепления с ключевым делом и ключевым путем, чтобы не потерять большое из-за малого, тянущего за собой все тело. Если это действительно неизбежно, связывающая сторона должна быть проинформирована о содержании изменения, точка сопряжения и связанные с ней зависимости должны быть четко обозначены, а ключевые моменты должны отслеживаться.
Принцип 7: Надежность
Изменения не должны снижать надежность самой системы (например, архитектура высокой доступности и устойчивость к данным). Если изменение заключается в том, что сама система будет принимать больше запросов на обслуживание, необходимо проверить, готовы ли пропускная способность, прерыватель цепи, регулирование и другие аспекты самой службы.
Принцип 8: Замена
Всегда существует риск полного сбоя системного обслуживания из-за изменения, и следует учитывать, есть ли другие каналы онлайн-бизнеса для его замены, такие как каналы распознавания лиц (переключение с Народного банка на Министерство общественной безопасности) и сообщения каналы уведомлений (переключение с сообщений APP на короткие сообщения и электронные письма), а затем есть ли в качестве альтернативы автономные каналы ручной обработки бизнеса.
Дополнительные материалы на PlainEnglish.io.
Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .
