Классический сценарий. Приходит новый менеджер (тут заранее стоит оговориться, что я, естественно, имею ввиду себя), смотри на всё, что происходит, говорит с людьми, делает какие-то выводы. Чаще всего эти выводы не совсем корректные. Потому как, по опыту, понять, что реально — да-да, ключевое слово РЕАЛЬНО, происходит в той или иной системе — нужно несколько месяцев. В то время, как среднестатистический руководитель (из тех, кого я знал) считает, что он понял, что надо делать вот прям на третий день. Выглядит это примерно так: ага, вы тут вообще неправильно всё делаете. Скрам у вас не скрам, ваши баш-скрипты для выкладки уродливые и выкладывают очень некошерно. Т.е. как бы намекает на то, что надо бы скрам и капистрану. С другой стороны, если всё-таки уделить чуть больше времени исследованиям, оказывается, что за углом, например, притаилась неработающая дев.среда, или полная задница с мониторингом. Другими словами — если система работает — пусть даже не идеально — лучше её не трогать. Лучше поискать те места, где вообще не работает. На моём пути была команда, которая решала крутейшие проблемы, связанные с оптимизацией производительности ресурса, при этом имея запас по прочности нагрузки раза в четыре. В итоге все силы были брошены на оптимизацию производительности. Ресурс работал быстро. Но при падении на бок пятисотил, а резерва не было. Другими словами произошла подмена цели. Лакомый кусок любого инженера — борьба с джойнами и нормализацией, выгнала с радаров настоящую беду — отсутствие резерва.
Читать далее «Эпизод 16. Не надо чинить то, что работает»