Это что-то типа служебной записки руководству компании после очередного совещания на тему архитектуры системы и развития вообще.
Автор (я) — один из разработчиков.
Контора — интернет-магазин.
----------------------
По архитектуре:
Архитектура не нуждается в оперативном изменении: за последние три-шесть месяцев подавляющее большинство серьезных проблем было вызвано вмешательством человека; все проблемы были оперативно решены.
Любые изменения архитектуры должны быть решением какой-либо проблемы, а не желанием почесать руки. Появление новых требований, новых бизнес-процессов относим к проблемам, и решаем по мере появления.
Т.о. приоритетным является вопрос своевременного планирования новых бизнес-процессов (а равно, и изменение существующих). Иными словами, чем раньше и точнее будет озвучено ТЗ, тем качественнее оно будет реализовано.
Желание разработчиков сделать все по фен-шую необходимо поощрять, но ориентироваться нужно на финансовый результат, а не на тщеславие и желание программистов заниматься творчеством. Однако, необходимо осознавать, что программисты — живые люди: они тоже хотят любить и быть любимыми.
Повседневный рефакторинг-оптимизация не отрицает серьезных изменений архитектуры в целом; вопрос заключается именно в выделении времени на анализ уже существующего кода и решений.
Про вероятное увеличение нагрузки:
Разговоры с рисованием квадратиков и связей между ними имеют малую ценность: как показывает практика, сломаться может все. Например, переписанный на xxx (исключительно ради повышения надежности) xxx не сломался, но перестал работать из-за зависшей виртуальной машины. Безусловно, необходимо понимать, что если бы xxx не переписали, проблемы появились еще раньше.
Т.о. первоочередное значение приобретает тестирование — как системы в целом, так и отдельных ее узлов. Приоритет необходимо отдавать критически важным узлам (неработающий xxx или неработающий xxx — разница очевидна).
Для организации (стресс-) тестирования существуют готовые решения (вплоть до платных сервисов), но ничто не мешает реализовать тестирование самостоятельно: все сотрудники xxx, услышав лай караульной собаки, создают по десять-двадцать-тридцать заказов; it-отдел выясняет: где именно возникли проблемы.
Полезными могут оказаться следующие действия:
а. на xxx определить наиболее тяжелые блоки; в случае повышения нагрузки эти блоки можно отключить, если это не приведет к критической потере функционала системы (например, блоки xxx, xxx, и т.д.) Критически важные блоки: каталог товаров, регистрация юзеров, покупка товаров, создание и оформление заказа. Очевидным является: чтобы измерить что-то, предварительно нужно создать инструменты для измерения.
б. создание "легковесной" копии сайта, на которую можно оперативно переключиться. На этой копии сайта оставить только критически важные вещи (см. выше), все остальное (частично — даже БД) — обнулить; из всего каталога товаров оставить только те, которые можно купить.
С другой стороны: опыт показывает, что в большинстве случаев нагрузка повышается НЕ лавинообразно, оставляя it-отделу время для продумывания и принятия мер противодействия, поэтому "сервер в Австрии на случай нападения марсиан" — излишество.
Про DDOS-атаки, упомянутые на совещании:
Вопросы решения DDOS-атак обычно возлагаются на хостеров (впрочем, в большинстве случаев, безосновательно); необходимо привлечь xxx, чтобы он обсудил этот вопрос с нашим хостером. На основании моих личных знаний и опыта: если сильно захотят, нас заддосят в любом случае, вне зависимости от принятых нами мер.
Глобально:
It-разработчики — это: реализаторы, механики, слесари, технари. Большая часть их рац-предложений сводится к "этот mysql запрос можно оптимизировать", роль программистов при обсуждении финансовой выгоды бизнес-процессов — минимальна; компания может потратить время программистов более выгодно. Для придумывания маркетологических акций существуют люди со специальным образованием.
Разработчикам требуется время и на обдумывание реализации ТЗ, и на реализацию ТЗ. Еще больше времени требуется в случаях: "да, в ТЗ этого не было, но это подразумевалось", "да, изначально в ТЗ этого не было, но теперь появилось".
Меня лично прошу освободить от участия в совещаниях-обсуждениях "нехай кладовщики по складу на роликах катаюццо" и "юридическая организация отделений мега-корпорации в регионах" — мне это неинтересно.
Итоги, выводы:
— оперативные решения и изменения не нужны, работаем в обычном темпе
— любые изменения архитектуры — ответ на новые бизнес-требования: нет новых требований — изменения не нужны
— осознаем важность своевременного и точного объяснения ТЗ
— занимаемся разработкой инструментов диагностики (как ручной, так и автоматической)
— определяем тяжелые блоки
— проводим (стресс-) тестирования
Чувствует сарказм. Если читатель воспримет этот сарказм как выпад в свою сторону, то толку от этой бумажки будет 0. Тебе стоит определиться, что важнее — изменить ситуацию или поязвить.
уверяю вас, руководители все это по 100 раз слышали. лучше ее сразу в корзину выкините, потому что потрясающе неконструктивно
-у вас там есть какие-то проблемы с человеческими ошибками, игнорирование человеческого фактора вполне себе архитектурный изъян. В любом случае вам следует не отпираться а предложить варианты решения проблемы
-вы по сути признали что нифига не понимаете в бизнес процессах, и особо не хотите понимать. Забавно что вы после этого хотите, цитирую "приоритетным является вопрос своевременного планирования новых бизнес-процессов". Это вообще кроме вас кому надо? Хотите чтобы что-то изменилось, кончайте плакать и займитесь сами, кроме вас некому
-Нежелание участвовать в совещаниях позиция понятная, но неправильная. Помнится еще макконел привел статистику (если память мне не изменяет) что ТЗ в среднем полно на 30% и точно на 70% (или наоборот, не суть). Вам приходится додумывать 80% ТЗ и чтобы сделать это правильно абсолютно необходимо понимать бизнес процессы и их вэлью для компании\клиентов. Пока что посещение совещаний самый простой и доступный способ обрести эти знания
ну и остальное сплошь одна вода
"...первоочередное значение приобретает тестирование — как системы в целом, так и отдельных ее узлов. Приоритет необходимо отдавать критически важным узлам..."
что именно тестировать будем и в каком порядке? где сроки, затраты, ожидаемый результат хоть в каких-нибудь попугаях? сошло бы и "давайте эксперимент поставим", через К-недель посмотрим что получилось
Здравствуйте, da_007, Вы писали:
_>Это что-то типа служебной записки руководству компании после очередного совещания на тему архитектуры системы и развития вообще.
"Что-то типа" служебной записки — это что-то типа туалетной бумаги? Если ты пишешь что-то руководству, то прежде всего, определись с сутью и формой твоего обращения (заявление, служебная записка, жалоба, требование, предложение...) Это не из-за того, что руководство с Марса прилетело и ему нужно два раза "ку", а потому, что так человеку проще настроиться на нужный лад, соответственно, тебя быстрее поймут и "дадут ход" твоей бумаге.
_>Автор (я) — один из разработчиков. _>Контора — интернет-магазин.
_>----------------------
_>По архитектуре:
_>Архитектура не нуждается в оперативном изменении: за последние три-шесть месяцев подавляющее большинство серьезных проблем было вызвано вмешательством человека; все проблемы были оперативно решены.
Что это за вмешательства? Кто эти люди? Как стоило бы модифицировать вашу систему, чтобы таких проблем не было?
_>Любые изменения архитектуры должны быть решением какой-либо проблемы,
Так у тебя их целая куча, как ты сам об этом сказал.
_>а не желанием почесать руки. Появление новых требований, новых бизнес-процессов относим к проблемам, и решаем по мере появления.
Это всё чепуха. Только несколько человек в вашей организации могут выдать вам задание на модификацию системы, от этого нужно плясать. Это не потому, что они такие венценосные, а потому, что фирма расходует на вас свои ресурсы и соответственно, не все имеют равные возможности этими ресурсами распоряжаться. Соображаешь, к чему я клоню? Правильно, к первой части решения проблемы "ненаписанного ТЗ". Тебе нужно апеллировать к тому, что ваши задания должны: а) утверждаться людьми, которые обладают определённой ответственностью, из чего следует б) эти задания должны выдаваться в письменной форме.
Но это с одной стороны, с формальной. А с другой стороны, если ты хочешь сказать о связи между реорганизацией бизнес-процессов и переработкой сайта, то так и говори: архитектура сайта может поменяться из-за новых требований к системе, а сами эти требования могут появиться из-за реорганизации фирмы, изменения ассортимента продаваемой продукции, маркетинговых мероприятий и т.п. А вводить какой-то новый обобщающий термин... Ну ты ведь не базовый класс придумываешь, правда? Выражайся по-людски.
_>Т.о. приоритетным является вопрос своевременного планирования новых бизнес-процессов (а равно, и изменение существующих). Иными словами, чем раньше и точнее будет озвучено ТЗ, тем качественнее оно будет реализовано.
Не выставляй себя на посмешище. Тебе хочешь добиться того, чтобы тебе выдавали полное письменное ТЗ — это главное. Появится оно из-за "планирования бизнес-процессов" или из-за того, что гендиректор захотел поэкспериментировать — не твоё дело.
_>Желание разработчиков сделать все по фен-шую необходимо поощрять,
Скажу тебе по секрету: этого не нужно делать никогда. Разработчики должны учитывать текущие и прогнозируемые потребности заказчика, а не фен-шуй. Именно исходя из потребностей проектируется архитектура и принимаются остальные решения, которые уже обставляются по фен-шую. Или по шуй-фену, для руководства — никакой разницы.
_>но ориентироваться нужно на финансовый результат, а не на тщеславие и желание программистов заниматься творчеством.
Ты уж определись, о чём идёт речь: о фен-шуе, который нужно поощрять, или о тщеславии программистов, которое поощрять не нужно.
_>Однако, необходимо осознавать, что программисты — живые люди: они тоже хотят любить и быть любимыми.
Бла-бла-бла. "Надо, но не надо, хотя, может и понадобиться, если захочется".
_>Повседневный рефакторинг-оптимизация не отрицает серьезных изменений архитектуры в целом; вопрос заключается именно в выделении времени на анализ уже существующего кода и решений.
1. "Рефакторинг-оптимизация" замени на "повседневные доработки и исправления ошибок". Что за манера, блин, клеить кучу существительных через дефис?!
2. Зачем нужен анализ уже существующего кода и решений? Для фен-шуя? Для творчества? Для удовлетворения тщеславия? Или чтобы пройти упражнения по очередной ОО-бредопедии?
_>Про вероятное увеличение нагрузки:
_>Разговоры с рисованием квадратиков и связей между ними имеют малую ценность: как показывает практика, сломаться может все. Например, переписанный на xxx (исключительно ради повышения надежности) xxx не сломался, но перестал работать из-за зависшей виртуальной машины. Безусловно, необходимо понимать, что если бы xxx не переписали, проблемы появились еще раньше.
Что за болтовня? Зачем это здесь? Что за мысль ты тут высказываешь?
_>Т.о. первоочередное значение приобретает тестирование — как системы в целом, так и отдельных ее узлов. Приоритет необходимо отдавать критически важным узлам (неработающий xxx или неработающий xxx — разница очевидна).
Каким образом второй абзац следует из первого? Мне, лично, кажется, что первоочередная задача — смена виртуальной машины, коль скоро имеющаяся может зависнуть.
_>Для организации (стресс-) тестирования существуют готовые решения (вплоть до платных сервисов), но ничто не мешает реализовать тестирование самостоятельно: все сотрудники xxx, услышав лай караульной собаки, создают по десять-двадцать-тридцать заказов; it-отдел выясняет: где именно возникли проблемы.
Проблемы возникнут у собаки, 100%. Тут даже IT-отдел не нужен. На кой чёрт тут это всё? Если ты хочешь провести краткий экскурс в проблематику тестирования, то расскажи хотя бы о том, что стресс-тестирование — это только подмножество задач тестирования, да ещё и не самое большое. Кроме того, я очень сомневаюсь, что даже все сотрудники разом смогут создать мало-мальски стрессовые условия для системы. Ну а если это так, то вам на самом деле нужно что-то менять, притом срочно. Для начала выкинуть учебники по фен-шую.
_>Полезными могут оказаться следующие действия:
_>а. на xxx определить наиболее тяжелые блоки; в случае повышения нагрузки эти блоки можно отключить, если это не приведет к критической потере функционала системы (например, блоки xxx, xxx, и т.д.) Критически важные блоки: каталог товаров, регистрация юзеров, покупка товаров, создание и оформление заказа. Очевидным является: чтобы измерить что-то, предварительно нужно создать инструменты для измерения.
Да-да, прочтя этот абзац руководство впадёт в священный трепет перед глубиной твоих талантов, падёт ниц и повысит тебе зарплату на 20%. бери эту хрень вообще — это частности, совершенно не нужные в записке, касающейся развития, перспектив и общей организации.
_>б. создание "легковесной" копии сайта, на которую можно оперативно переключиться. На этой копии сайта оставить только критически важные вещи (см. выше), все остальное (частично — даже БД) — обнулить; из всего каталога товаров оставить только те, которые можно купить.
Это тоже. Это всё должно отражаться в отдельных документах.
_>С другой стороны: опыт показывает, что в большинстве случаев нагрузка повышается НЕ лавинообразно, оставляя it-отделу время для продумывания и принятия мер противодействия, поэтому "сервер в Австрии на случай нападения марсиан" — излишество.
Ну, без наукообразия никуда, это понятно... Посмотри в интернете значение слова "лавинообразно" применительно к техническим системам. На самом деле, ты имел в виду другое: что как правило, нагрузка растёт достаточно медленно, чтобы IT-отдел успел принять меры, предотвращающие отказ системы. Естественный вопрос отсюда: каковы предельные значения этой самой нагрузки и когда (по прогнозам) IT-отделу на самом деле придётся дёргаться. Что если завтра ваш интернет-магазин окажется единственным продавцом какой-нибудь супер-пупер Виагры №151 и на него ломанутся все покупатели СНГ?
_>Про DDOS-атаки, упомянутые на совещании:
_>Вопросы решения DDOS-атак обычно возлагаются на хостеров (впрочем, в большинстве случаев, безосновательно);
Школа русских язык училась два? Может быть, ты имеешь в виду банальную "защиту от DDOS-атак", нет?
_>необходимо привлечь xxx, чтобы он обсудил этот вопрос с нашим хостером. На основании моих личных знаний и опыта: если сильно захотят, нас заддосят в любом случае, вне зависимости от принятых нами мер.
Короче говоря, об этом можно вообще не говорить — либо упомянуть только о том человеке, который поговорит с хостером про защиту. Остальной словесный мусор — выкинуть.
_>Глобально:
О-о-о... Наукообразие + глобальность. Стальная поступь железного сапога программиста.
_>It-разработчики — это: реализаторы, механики, слесари, технари. Большая часть их рац-предложений сводится к "этот mysql запрос можно оптимизировать", роль программистов при обсуждении финансовой выгоды бизнес-процессов — минимальна; компания может потратить время программистов более выгодно. Для придумывания маркетологических акций существуют люди со специальным образованием.
_>Разработчикам требуется время и на обдумывание реализации ТЗ, и на реализацию ТЗ. Еще больше времени требуется в случаях: "да, в ТЗ этого не было, но это подразумевалось", "да, изначально в ТЗ этого не было, но теперь появилось".
Точно — больше времени? Или это так — для красного словца?
_>Меня лично прошу освободить от участия в совещаниях-обсуждениях "нехай кладовщики по складу на роликах катаюццо" и "юридическая организация отделений мега-корпорации в регионах" — мне это неинтересно.
А откуда ты собираешься брать ту самую информацию о подразумевающихся моментах в ТЗ, как не из этих совещаний? Дружище, программист обязан владеть настолько полными сведениями о контексте, насколько это вообще возможно. А ты отказываешься от такой лакомой возможности! Ты чайник или красноглазик?
_>Итоги, выводы:
Я так и не понял, это резюме к чему? Ты здесь рассуждаешь (если рассуждаешь) только о текучке (ирония вполне объяснима). Ну, ещё прослеживается мысль: "отъ..итесь!"
_>- оперативные решения и изменения не нужны, работаем в обычном темпе
Блин, сленг программистов зачастую превосходит отпетых бюрократов.
_>- любые изменения архитектуры — ответ на новые бизнес-требования: нет новых требований — изменения не нужны _>- осознаем важность своевременного и точного объяснения ТЗ
Вот тут у тебя невязка (на мой взгляд, во всяком случае). Ты хочешь, чтобы тебе объяснили ТЗ, и одновременно отбрыкиваешься руками и ногами от участия в "глобальных" процессах компании. Попробуй ответить на вопрос: кто будет формулировать это самое пресловутое ТЗ?
_>- занимаемся разработкой инструментов диагностики (как ручной, так и автоматической)
Поправьте меня, если я ошибаюсь, но этого никак не следует из текста записки. У тебя там вообще не упомянута разработка собственных средств диагностики и тестирования. Или это по фэн-шую?
_>- определяем тяжелые блоки
Как тут правильно заметили, "тяжёлые блоки" — это глокая куздра. Что это такое? Снова узкопрофессиональный сленг на ровном месте. Это не считая того, что этот и следующий "выводы" вообще здесь не нужны.
_>- проводим (стресс-) тестирования
Ну зачем здесь это?
_>----------------------
_>Ы? Вроде очевидные вещи, доступным языком?
Детский лепет, наукообразный, 1 шт. Извини за прямоту. От начала и до конца. Руководство, конечно, эту бумагу от тебя примет, руку пожмёт, по плечу похлопает и всё остальное по списку. Только потом оно её забросит куда подальше, как страшный сон и правильно сделает.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
On 14.01.2011 10:16, da_007 wrote: > Это что-то типа служебной записки руководству компании после очередного > совещания на тему архитектуры системы и развития вообще. > Автор (я) — один из разработчиков. > Контора — интернет-магазин.
...
> Ы? Вроде очевидные вещи, доступным языком?
Два момента:
1. Неясен пассаж про "тяжёлые блоки", ибо разделение системы на части c
целью обеспечения возможности их независимого существования — это и есть
изменение архитектуры, которую, согласно предыдущим утверждениям, менять
не надо.
2. Предложение о том, чтобы стресс-тестами занимались сотрудники, а
It-отдел "потом что-то выяснял" выглядит странновато. Возьмите тот же
самый selenium или jmeter — для того чтобы массированно создавать заказы
в базе этого должно хватить.
Ну и внутреннего Петросяна я бы ограничил, но это зависит, конечно, от
контекста.
приоритетным является вопрос своевременного планирования новых бизнес-процессов
я ожидал увидеть в конце что-то вроде "Сделайте меня менеджером!" Как уже заметили, из-за большого количества попыток сарказма, все выглядит, как цирковое представление.
_>Желание разработчиков сделать все по фен-шую необходимо поощрять, но ориентироваться нужно на финансовый результат, а не на тщеславие и желание программистов заниматься творчеством. Однако, необходимо осознавать, что программисты — живые люди: они тоже хотят любить и быть любимыми.
Здравствуйте, Геннадий Васильев, Вы писали:
_>>It-разработчики — это: реализаторы, механики, слесари, технари. Большая часть их рац-предложений сводится к "этот mysql запрос можно оптимизировать", роль программистов при обсуждении финансовой выгоды бизнес-процессов — минимальна; компания может потратить время программистов более выгодно. Для придумывания маркетологических акций существуют люди со специальным образованием.
Чем раньше IT-персонал привлекается к обсуждению организационных вопросов, которые могут повлиять на IT-инфраструктуру — тем лучше. А на подобных совещаниях зачастую проговаривается то, что потом становится "подразумеваемым".
Ну и как обычно — ты несколько невпопад употребляешь термин "бизнес-процесс".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
_>Это что-то типа служебной записки руководству компании после очередного совещания на тему архитектуры системы и развития вообще. _>Автор (я) — один из разработчиков. _>Контора — интернет-магазин.
Всем огромное спасибо за внимание и потраченное на меня время.
Здравствуйте, da_007, Вы писали:
_>Здравствуйте, da_007, Вы писали:
_>>Это что-то типа служебной записки руководству компании после очередного совещания на тему архитектуры системы и развития вообще. _>>Автор (я) — один из разработчиков. _>>Контора — интернет-магазин.
_>Всем огромное спасибо за внимание и потраченное на меня время.
Имхо, написано толково и по делу.
Стиль в самую меру разбавляет сухость предмета записки.
Думаю, топ-руководство с удовольствием прочитает, похмыкивая, но виду не подаст.
Замы, нач. и зав. отреагируют примерно также как большинство юношей в этой ветке. Поэтому они и зам-завы, а не топы.
Дерзайте в таком же стиле и далеко пойдете.
Удачи.
Kvd>Думаю, топ-руководство с удовольствием прочитает, похмыкивая, но виду не подаст. Kvd>Замы, нач. и зав. отреагируют примерно также как большинство юношей в этой ветке. Поэтому они и зам-завы, а не топы. Kvd>Удачи.
Да-да, я уже вижу эту картину как топы говорят, парень чего ты там жмёшься около почек в программистах, давай к нам, в президиум.
Здравствуйте, De-Bill, Вы писали:
_>>Всем огромное спасибо за внимание и потраченное на меня время.
DB>А результаты-то какие? Если не секрет.
Я сюда написал, по большому счету, поинтересоваться "вы бы меня выгнали за такие письма?" =)
Но свой вопрос, как сейчас, расшифровывать не стал, чтобы выслушать и мнения "вообще".
Про петросянство — в общем, справедливо отметили... Но слишком сухо — писать не хочется, если "чуть-чуть" — то, думаю, можно...
У нас не сильно большая контора, как следствие, — с начальниками на "ты", и можно чуть-чуть поулыбаться.
Касательно вывода "и поэтому увеличьте мне зарплату" — я получаю больше других программистов, поэтому такого подтекста не было.
Возможное неправильное употребление терминов... "у нас так принято" =) Т.е. я в письме оперировал разными терминами — в том контексте, которыми ими оперировали другие люди на "том" совещании — чтобы всем было проще; возможно, это неправильно, но если все называют сервер "хреновиной" — зачем мне занудничать?
Результаты — пока никаких... Не выгнали — уже хорошо =)
Собственно, из "записки" и следует, что не надо бросаться грудью на амбразуру, что спокойно работаем дальше, обращая внимание на "а чо будет, если траффик увеличится", но не делая из этого священной коровы — где-то так пока и получается. Контора — не сильно большая, но и не сильно маленькая, чтобы за неделю что-то серьезно изменилось на основании моего письма; сейчас ждут предложений "начальника транспортного цеха", как соберут мнения всех — тогда последуют какие-то выводы, направленность программистов чуть-чуть изменится.
Хотите чтобы что-то изменилось, кончайте плакать и займитесь сами, кроме вас некому
