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