{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

Как бизнесу защититься от ошибок программистов

Привет, с вами Алексей, CEO компании Verdat. Сегодня расскажу о концепции защищенного окружения.

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

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

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

Следует понимать, что ошибки могут произойти как из-за промаха инженера, так и по злому умыслу тех, кто решил нанести вред компании или обогатиться за её счёт. А велика ли разница, случайно или намеренно вам нанесли убытки?

Ну, довольно риторических вопросов, переходим к описанию алгоритма действий. Он состоит всего из трёх шагов.

Шаг первый.

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

Шаг второй.

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

Шаг третий, самый важный и самый сложный.

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

Чем больше программа, тем больше в ней ошибок и тем проще их совершить. К примеру, если в программе 0 строчек кода, то ошибок в ней точно нет. По статистике на 1000 строк кода в среднем совершается одна ошибка.

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

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

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

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

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

Возражение:
Давайте не будем драматизировать. Мы пишем достаточно надежный код, и риск сильно преувеличен.
Ответ:
Во-первых, решение о степени риска и его принятии или непринятии может выноситься только бизнес-лидером, а никак не инженерами, которые получат зарплату даже после промаха, от которого компания уйдёт в глубокий нокаут. Во-вторых, в этом вопросе нужно следовать правилу "Оружее всегда заряжено". Оно гласит, что если вы даже на 200% уверены, что в ружье нет патронов и опасность не грозит, нужно всё равно обращаться с ним так, как будто оно может выстрелить. Когда-нибудь это спасет вам жизнь. Помните правило Мёрфи: если что-то может пойти не так, то обязательно пойдёт.

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

0
Комментарии
-3 комментариев
Раскрывать всегда