Highload — тот ещё секс в нашей жизни. Можно ли научить сексу заранее тех, кто не нюхал пороха?

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

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

Как итог: новый спецкурс на Факультете информационных технологий в НГУ.
Два года, два потока.
Переписанная два раза программа, мысли переписать снова.
Трудности с лабораторными стендами. Пошёл через облака — отдал своих кровных 5 000 за время, пока настраивал, и две пары лабораторной работы в Azure.
Отказался от идеи показать для сравнения мир Microsoft с его release manager и desired state config.
С удивлением включил в программу вопросы непрерывной интеграции, а думал говорить только про поставку.
Мясо, нужно больше мяса, но нужны помощники, где взять опытных волонтеров со сбитыми костяшками.
Мучения с погружением в кухню рецептов, как показать и дать потрогать, чтоб поняли, не имея опыта эксплуатации.
Когда это даст эффект, если даст?

Вопросы в темноте....

P.S. И да, я рассказываю про ITIL и не считаю это лишним.