Огляд
ПЗ оборонних технологій — це звичайна інженерія за чотирьох обмежень, які решта цього сайту вважає неіснуючими: немає надійної мережі, супротивник фінансований і терплячий, хибний вихід коштує значно більше за поганий квартал, а користувач не сидить за столом і не має часу вчитися. Майже все інше на цьому сайті припускає протилежне всім чотирьом. Приберіть їх — і інженерія не стане екзотичною, вона стане суворою. Ця сторінка називає чотири обмеження, показує, що кожне з них заміщає, і описує ті частини робочого середовища, які дивують людей із продуктової розробки.
- Обмежень
- Чотири, і вони множаться
- Центр проєктування
- Випадок збою
- Означення готовності
- Містить помилку
Чотири обмеження і що кожне з них заміщає
Не існує єдиного «оборонно-технологічного» стилю інженерії, і пошук такого — найшвидший шлях зробити щось, що вражає на демонстрації й ламається у використанні. Натомість існує набір припущень, які звичайна практика робить мовчки, а цей домен зробити не може. Чотири з них варті того, щоб їх назвати, і кожне має конкретний наслідок, а не загальний настрій серйозності.
Перше змінює найбільше коду. «Мережа ненадійна» — речення, з яким погодиться кожен бекенд-інженер і під яке дуже мало систем справді збудовано, бо на практиці воно означає «повільна або зрідка з утратами»: повтор це вирішує. Тут воно означає «відсутня» — годинами, без попередження, і обидві сторони працюють далі, поки її немає. Система, збудована під затримку, повторює й зрештою вдається; система, збудована під розрив, виконує свою роботу сама, записує, що зробила, і узгоджується, коли контакт повернеться. Це різні архітектури, а не різні значення тайм-ауту.
Що справді змінюється в щоденній практиці
Обмеження лишаються абстрактними, доки не поставити їх поруч із практиками, які вони перевертають. Таблиця нижче свідомо написана проти решти цього сайту: кожна ліва клітинка є тим, що обстоюють деінде на цих сторінках і що там правильне.
| Звичайна практика | Що заступає це тут | Бо |
|---|---|---|
| Розгортати кілька разів на день; лагодити вперед | Релізи рідкі, підписані, поетапні й оборотні на самому пристрої | Пристрій може бути недосяжним тижнями, тож версія, що на ньому, мусить бути безпечною сама по собі тижнями. |
| Спостерігати продакшн і ітерувати за реальним використанням | Записані логи, зібрані пізніше, плюс симуляція як головний цикл зворотного звʼязку | Живого потоку телеметрії для читання немає, і часто немає як спитати оператора, що сталося. |
| Додати залежність, коли вона економить тиждень | Кожна залежність — рішення про ланцюг постачання з власником і записом походження | Супротивник теж читає ваш список залежностей, а скомпрометована збірка доходить до всіх пристроїв одразу. |
| Цілитися у високу доступність у відсотках | Цілитися у плавну деградацію: назвати, що працює на кожному рівні втрат | Девʼятки описують сервіс, що або живий, або ні. Тут цікавими є саме часткові стани. |
| Означення готовності: працює й тести проходять | Означення готовності містить те, що воно робить, коли помиляється, заглушене, захоплене чи без нагляду | Випадок збою тут не є межовим випадком: це очікувані умови роботи. |
Робоче середовище, про яке ніхто не попереджає
Технічні обмеження — та половина, яку обговорюють. Друга половина — як приходить робота, як її оцінюють і скільки вона живе, — відрізняється від продуктової розробки достатньо, щоб сказати про це прямо.
Вимоги приходять документами
Не беклогом, який ви формуєте через дискавері. Значна частина майстерності — прочитати специфікацію, написану тим, хто ніколи вас не зустріне, і знайти в ній речення, що вирішує архітектуру.
Сумісність є обовʼязковою
Вашу систему попросять обмінюватися даними з системами, обраними кимось іншим, часто старшими за неї й незмінними. Стандарти повідомлень є вимогою, а не питанням смаку.
Життєві цикли довгі
Десять–двадцять років є нормою. Це змінює кожне рішення про залежність і формат даних, а «потім перепишемо» стає обіцянкою, яку вам згадають.
Доказ є частиною роботи
Показати, що воно працює, є окремим результатом із власною оцінкою трудовитрат: протоколи тестів, простежуваність від вимоги до тесту, аргумент, чому безпекове обґрунтування тримається.
Ще два обмеження є юридичними, а не технічними, і знати їх варто до того, як берете роботу, а не після. Значна частина цього софту підпадає під експортний контроль, а це обмежує, хто може тримати вихідний код, де його можна збирати і кому можна казати, що він робить, — правило, яке дістає навіть до звичайних рішень на кшталт того, у якому регіоні хмари живе репозиторій. І дуже багато тут є подвійного призначення: той самий конвеєр детекції служить пошуково-рятувальним роботам, обліку тварин і моніторингу кордону. Це справжня властивість галузі — і водночас не дозвіл пропустити питання, для чого система. Чесна позиція: це питання належить дизайн-рев’ю, з письмовою відповіддю, поруч із моделлю загроз.
Людина в контурі як інженерна вимога
Цю фразу вживають достатньо вільно, щоб вона нічого не означала. Як інженерна вимога вона є конкретною й розкладається на властивості, які можна перевірити. Людина є в контурі, коли вона мусить діяти до того, як станеться дія з наслідками; людина є над контуром, коли система діє, а людина може її спинити; і немає ні того, ні іншого, коли людині показують результат, який вона реально не може ні оцінити, ні перервати. Третій випадок є найчастішим і зазвичай виникає випадково, а не за рішенням.
- Людина мусить мати достатньо часу вирішити. Діалог підтвердження з тайм-аутом у дві секунди — не нагляд, а печатка з додатковою затримкою.
- Людина мусить бачити чому. Число певності без доказу за ним — який сенсор, якого віку, з чим збіглося — ніхто оцінити не може.
- Відмовитися має бути так само легко, як погодитися, і не має виглядати помилкою. Якщо інтерфейс робить «ні» важчим за «так», контур є декоративним.
- Рішення мусить бути записане: що показали, що обрали, коли й хто. Без цього запису поганий результат не розібрати, а систему не покращити.
- Упередження на користь автоматики є проблемою дизайну, а не навчання. Система, що переважно має рацію, привчає людей не перевіряти, — тож інтерфейс мусить і далі робити непевні випадки на вигляд непевними.
Антипатерни, які варто назвати
- Будувати під демонстрацію: гарна погода, повна батарея, сильний звʼязок і автор поруч.
- Вважати модель загроз кроком рев’ю наприкінці, де вона може дати лише список того, що вже не встигнеш змінити.
- Припускати, що оператор прочитає інструкцію. Не прочитає, і замість неї в нього буде інтерфейс.
- Переносити хмарну архітектуру цілком у середовище без хмари: виходить система, недоступна саме тоді, коли потрібна.
- Лишати питання про призначення системи комусь іншому на тій підставі, що вона подвійного призначення.
Коли це застосовувати
Застосовуйте, коли
- Як першу сторінку розділу: решта пʼяти припускають ці чотири обмеження, не повторюючи їх.
- Коли вирішуєте, чи переноситься звичайна архітектура в середовище без звʼязку, зі спротивом або без нагляду.
- Як чеклист для дизайн-рев’ю: що станеться, коли воно помиляється, заглушене, захоплене чи саме.
- Щоб налаштувати очікування команди, що переходить сюди з продуктової розробки, — до першого спринту, а не після.
Уникайте, коли
- Як джерело конкретики: механізми живуть на пʼяти тематичних сторінках, і ця свідомо їх не повторює.
- Як аргумент, що цей домен потребує інших основ. Він потребує тих самих, дотриманих суворіше.
- Як заміну письмовій моделі загроз: вона є специфічною для системи і не успадковується зі сторінки.
- Щоб виправдати відмову від звичайної інженерної дисципліни. Кожна практика з інших чотирьох розділів діє й тут.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.