Информационная безопасность, производительность и надежность приложений
Joe Schaefer.
«Нефункциональная» программная инженерия вращается вокруг трех ключевых проблем: безопасность, производительность и надежность (SPR); в то время как «функциональная» разработка программного обеспечения включает в себя нормальный жизненный цикл разработки программного обеспечения на основе функций. Правильно СПИСОК 800-160v1r1.
Некоторые фирмы получили невероятную ценность, разделив функциональную от нефункциональной разработки программного обеспечения на две независимые иерархии в инженерной части организационной схемы. Вы можете найти архитекторов SPR, таких как я, чтобы возглавить такую команду SPR, с гибким сочетанием развивающихся, подчиненных ролей:
Критически важная системная инженерия (ориентированная на создание и мониторинг метрик наблюдаемости, инструмент динамического отслеживания и совместимое построение среды выполнения, а также анализ полного спектра профилирования для разработки высокоэффективных решений для обеспечения производительности / безопасности),
Triage Engineering (ориентированный на обработку свалки трассировки стека как в разработке, так и в производстве, и на получение основных технических проблем, сообщенных надлежащей группе разработки для решения),
Инженерное обеспечение качества (ориентированное на создание программного обеспечения для тестирования SPR и соответствующих отчетов),
Инженерное обеспечение качества данных (сосредоточено на предоставлении автоматизированной инфраструктуры отчетности/обработки/визуализации для деятельности по сортировке и обеспечению качества).
Создание специальной группы SPR включает в себя некоторые организационные проблемы. На уровне руководства должно быть обеспечено, чтобы эксперты по производительности/безопасности в SPR имели некоторые разумные ожидания того, что их рекомендации и успешно протестированные, представленные исправления программного обеспечения будут своевременно включены в производственную кодовую базу. Чтобы создать необходимые эффективные рабочие отношения между функциональными и нефункциональными инженерными командами, инженеры по производительности должны быть частично встроены в функциональные команды разработки продуктов в качестве коллег с привилегиями рецензирования / фиксации на базе кода.
Имея специальную команду SPR, руководство может освободить инженеров по продуктам (делающих функциональную разработку) от необходимости создавать / управлять / тестировать макеты ваших производственных сред, которые подходят для производительности / масштабирования / безопасности / долговечности / надежности работы. Многие команды просто не имеют циклов, которые можно потратить на это, несмотря на важность правильного масштабирования своих облачных активов и зависимых сред выполнения программного обеспечения для обеспечения быстрого роста.
Существует также значительная специализация работы с точки зрения инструментов наблюдения и методов отслеживания на основе ядра, что хорошие системные инженеры проходят, чтобы оставаться на вершине своей области. Трудно нанять эти вспомогательные навыки при поиске качественных талантов для традиционных инженеров по продуктам и/или специалистов по обработке данных на основе agile.
Надежное, безопасное, масштабируемое, рентабельное, высокопроизводительное программное обеспечение находится в пределах досягаемости любой небольшой / средней инженерной команды с правильными инвестициями в SPR. Охват.