Потому я и говорю, что вопрос экзистенциальный. Каждый сам должен решить, на что он готов ради того, что для него важно — тогда у него появятся силы за это бороться. А задача тимлида в этой ситуации — объяснить команде, что самое правильное — победить задачу, говоря примерно следующее: «Что бы вы, ребята, ни делали, вы — профессионалы, и ваш путь в жизни и на рынке — быть профессионалом, и если вы хотите лучшего будущего — направьте ваши усилия на оттачивание профессиональных навыков. Вы можете сменить место работы, но кому нужны сотрудники, бегущие от задач? Либо мы все вместе решаем эту задачу, либо это начало конца моей карьеры. И ваших тоже.»
Прибавка может быть 10-20%. Это психологический момент. Члены команды должны иметь основание считать, что они стараются потому что их стали выше ценить, а не потому что их испугали.
Вы описали экзистенциальную проблему и ищете способ её решения в плоскости социальных взаимодействий. Однако, экзистенциальные проблемы решаются не через социальные отношения, а через осознание себя и своего пути. Руководителю проекта следует задаться вопросами «Кто я и что вообще здесь делаю? Профессионал ли я? К чему я стремлюсь? Куда я веду команду? Во что я верю?» (для сравнения, в вашем варианте руководитель проекта задаётся вопросом «как мне решить ситуацию с наименьшими потерями _для себя_?»).
Подобные экзистенциальные кейсы (с внешним давлением) — это изменение характера в итоге и неизбежные потери в процессе. С этими потерями нужно просто смириться, каждый в команде что-то потеряет, нужно просто идти к конечной цели, выкладываться по полной. Вопрос только в том, какова она — конечная цель для каждого. Кому важнее быть профессионалом, кому — заработать денег, кому — уйти от ответственности, кому — проявить характер. Каждый в команде должен сам для себя найти ответ на этот вопрос, который поставит перед ним тимлид. Но прежде чем ставить этот вопрос перед командой тимлид должен решить его сам. А дальше как в этом видео youtu.be/UjQQVJWzlLI
После этого у команды есть шанс отрастить яйца и выйти на новый уровень слаженности и результатов. Например, они могут подойти к техдиру и сказать:
— Вы сами должны понимать, что запугивание — в долгосрочной перспективе демотивирующий фактор. Своей угрозой Вы фактически положили начало конца кадровому изобилию в компании, ибо никто теперь не сможет работать без оглядки. Если мы не сдавали проект в срок, а после ваших угроз сдадим — то это будет воспринято коллективом и начальством как зелёный свет угрозам. Если мы прогнёмся сейчас — что помешает вам угрожать увольнением в будущем? А жить и работать в страхе невозможно, и люди начнут уходить, начиная с лучших. Поэтому, чтобы избежать такого сценария, почему бы Вам не внести компенсаторный мотивирующий фактор, например, в виде бонуса за сданный в срок проект? В самом деле, если этот проект так важен для Вас, что мы должны работать в авральном режиме — то этот авральный режим нужно компенсировать. У нас жёны, дети. Мы могли бы форсировать проект, выходя на работу в субботу-воскресенье, но что мы за это получим? Вы пытаетесь переложить на нас Ваши риски — так риски предполагают компенсацию. Как насчёт +50% к з/п? Нет? Ну что ж, в нынешних условиях сдать проект в срок нет возможности, по итогам Вы уволите пол-команды, это точно не улучшит результативность по проекту, через какое-то время он закроется, и в итоге уволят уже Вас.
Итого, последовательность шагов для тимлида:
1. Решить для себя, кто он, и что делает на текущей должности и в текущей команде,
2. Озвучить проблему коллективу и спросить «почему мы фейлим сроки? мы профи или кто? вы понимаете, что мы дошли до края, до ребра вопроса, так сказать? мы здесь нужны для решения конкретной задачи, а сделать мы её не можем. это вопрос даже не наличия работы, это вопрос профессиональной гордости.»
3. Когда команда перебурлит и мнения начнут склоняться к «мы профессионалы и готовы это доказать, в первую очередь самим себе» — пойти к техдиру, объяснить механизм демотивации-мотивации и выбить компенсаторный мотивирующий фактор в виде увеличения зп для всей команды.
4. После этого идти к команде и озвучивать им: «Зарплату нам подняли, теперь заживём. Но если не сдадим проект в очередной срок — уволят всех. И меня. Потому что мы либо решаем задачу, либо не нужны.»
И тогда будет шанс уложиться в срок. Потому что главное во всей истории — укладываться в срок.
Человеческий мозг так устроен, что ему проще посмотреть как пользуется предметом другой человек, чем воспроизвести мысленную модель по техническому описанию или чертежу этого предмета. Мы, люди, от природы своей имитаторы. Поэтому, идеальный вариант инструкции — видеоуроки с пояснением нюансов (ответами на частые вопросы). На видео хорошо видна последовательность действий, поэтому оно даёт максимальную лёгкость вхождения в тему. За видео по степени понятности и лёгкости вхождения следуют пошаговые инструкции «что делать чтобы получить Z». На последнем месте — техническая документация.
Вы только что изобрели асинхронную запись. Только ОС сбрасывает буфер на диск не раз в 10 минут, а раз в несколько секунд.
Использовать асинхронную запись не мешает ничто кроме риска потерять данные (если они критичны). Поэтому журнал транзакций в СУБД выполняется в синхронном режиме, и это влияет на производительность I/O. А логи веб-сервера могут вестись в асинхронном режиме (скорее всего, так и есть).
Кроме того, лог можно направлять в syslog и отправлять по сети на соседний сервер. Тоже выход.
А я имел ввиду ситуацию, когда и лог, и раздаваемый контент находятся на одном диске. Всё дело в количестве IOPs, а также в том, как именно nginx ведёт лог — синхронно или асинхронно (я не знаю этого наверняка, но, возможно кто-то другой здесь знает). Если синхронно, то любой запрос к статике — это, грубо говоря, 2 обращения к диску — на чтение целевого файла и на запись лога. Если асинхронный — то ситуация получше, запись кидается в очередь в оперативной памяти, а ОС сама записывает на диск когда ей удобнее.
Да, логи пишутся в конец файла. Однако, если диск HDD, плюс на этом же диске хранится раздаваемая статика, БД и т.п., то головка диска будет совершать кульбиты туда-сюда, и IOPsы просядут.
С точки зрения производительности — лучше на другой физический диск на этом же сервере, с точки зрения безопасности — наверное Вы правы. Можно использовать syslog.
Строго говоря, логирование может сказаться на быстродействии, если дисковое I/O загружено под завязку, либо если объём логов слишком велик. В случае СУБД рекомендуется выносить лог транзакций на отдельный физический диск, хранящий исключительно лог. В этом случае скорость работы СУБД ограничится потоковой скоростью записи на диск (~100+ МБ/с). Полагаю, для Nginx как и для других логирующих систем этот принцип будет так же справедлив.
> писать строки в одинарных кавычках — это вредный совет?
_надрачивать_ на одинарные кавычки — вредный совет
> А его ещё и в официальной документации дают
там дают совет «не забудьте, что в двойных кавычках происходит автозамена $-переменных на их значения», а вовсе не «одинарные кавычки быстрее двойных»
О, тут интересный момент. Сегментирование рынка бывает разным. Бывает, цену сбавляют для тех, кто в принципе имеет маленький доход, например, для физических лиц. Как отличается виста ультимэйт про от какой-нибудь хоум кастратед мобайл. А бывает цену сбавляют потому что потребитель всё равно платить не будет. Деньги есть, а он не платит, потому что жадный и борзый. Вот с Китаем так же — была бы зависимость — мелкомягкие бы на них давили, а они уступили.
За тот же и больше? Фантастикой попахивает. Нет, не отказался бы :)
Вернёмся к нашим китайцам? Проблема для мелкомягких в том, что Китай неподконтролен остальному миру, в частности США. Конечно, Китай состоит в ВТО, и обязан соблюдать правила игры. Но в большой политике честность не всегда играет решающую роль, а Китай в экономическом смысле сильная держава.
В общем, китайцы пользуются интеллектуальными достижениями всего мира, и не только софтом, но и идеями вообще. Мелкомягкие не могут запретить китайцам использовать свой софт, потому что китайцы его уже используют. Всё что могут мелкомягкие — это снизить цены и сделать вид, будто делают китайцам одолжение. На самом деле это китайцы делают одолжение. Никаких административных гонений там не будет, потому что это Китай.
Понятно. У меня немного по-другому, я собой не торгую в принципе, и телом, и временем. Потому и говорю, что вырученная сумма равна себестоимости, если понятие себестоимости вообще можно применить к оценке собственного времени.
Я б предложил другой вопрос — продаю ли я труд других людей по себестоимости. Да, иногда даже себе в убыток. Что произойдёт, если повышать цену? Те люди, которым я делаю заказы, будут получать больше. Чем отличается такой подход от корпоративной жадности? Тем, что корпоративная жадность приводит к раздуванию бюрократического аппарата — 10 менеджеров на 1 программиста :)
Не товары/труд, а оценка снаружи/изнутри. Человек смотрит на все товары снаружи, и на чужой труд тоже снаружи, только на свой — изнутри. Назовите себестоимость вашей почки, например. Т.е. ту сумму, в которую она вам обошлась.
Нет конечно.
Вы задали некорректный вопрос. Себестоимость труда не оценивается изнутри, её можно оценить только снаружи. Т.е. если я перепродаю труд другого человека — я могу сделать наценку или наоборот скидку, в этом случае себестоимость (исходная величина) — сколько я заплатил этому человеку. Если же я продаю свой труд — то во сколько бы я его ни оценил, сумма будет равна себестоимости.
> Думаю, и Путин, и Медведев и прочие хорошо понимают эту несложную истину, потому и вступление в ВТО идёт со скрипом, и государство практически не борется с пиратством.
Подобные экзистенциальные кейсы (с внешним давлением) — это изменение характера в итоге и неизбежные потери в процессе. С этими потерями нужно просто смириться, каждый в команде что-то потеряет, нужно просто идти к конечной цели, выкладываться по полной. Вопрос только в том, какова она — конечная цель для каждого. Кому важнее быть профессионалом, кому — заработать денег, кому — уйти от ответственности, кому — проявить характер. Каждый в команде должен сам для себя найти ответ на этот вопрос, который поставит перед ним тимлид. Но прежде чем ставить этот вопрос перед командой тимлид должен решить его сам. А дальше как в этом видео youtu.be/UjQQVJWzlLI
После этого у команды есть шанс отрастить яйца и выйти на новый уровень слаженности и результатов. Например, они могут подойти к техдиру и сказать:
— Вы сами должны понимать, что запугивание — в долгосрочной перспективе демотивирующий фактор. Своей угрозой Вы фактически положили начало конца кадровому изобилию в компании, ибо никто теперь не сможет работать без оглядки. Если мы не сдавали проект в срок, а после ваших угроз сдадим — то это будет воспринято коллективом и начальством как зелёный свет угрозам. Если мы прогнёмся сейчас — что помешает вам угрожать увольнением в будущем? А жить и работать в страхе невозможно, и люди начнут уходить, начиная с лучших. Поэтому, чтобы избежать такого сценария, почему бы Вам не внести компенсаторный мотивирующий фактор, например, в виде бонуса за сданный в срок проект? В самом деле, если этот проект так важен для Вас, что мы должны работать в авральном режиме — то этот авральный режим нужно компенсировать. У нас жёны, дети. Мы могли бы форсировать проект, выходя на работу в субботу-воскресенье, но что мы за это получим? Вы пытаетесь переложить на нас Ваши риски — так риски предполагают компенсацию. Как насчёт +50% к з/п? Нет? Ну что ж, в нынешних условиях сдать проект в срок нет возможности, по итогам Вы уволите пол-команды, это точно не улучшит результативность по проекту, через какое-то время он закроется, и в итоге уволят уже Вас.
Итого, последовательность шагов для тимлида:
1. Решить для себя, кто он, и что делает на текущей должности и в текущей команде,
2. Озвучить проблему коллективу и спросить «почему мы фейлим сроки? мы профи или кто? вы понимаете, что мы дошли до края, до ребра вопроса, так сказать? мы здесь нужны для решения конкретной задачи, а сделать мы её не можем. это вопрос даже не наличия работы, это вопрос профессиональной гордости.»
3. Когда команда перебурлит и мнения начнут склоняться к «мы профессионалы и готовы это доказать, в первую очередь самим себе» — пойти к техдиру, объяснить механизм демотивации-мотивации и выбить компенсаторный мотивирующий фактор в виде увеличения зп для всей команды.
4. После этого идти к команде и озвучивать им: «Зарплату нам подняли, теперь заживём. Но если не сдадим проект в очередной срок — уволят всех. И меня. Потому что мы либо решаем задачу, либо не нужны.»
И тогда будет шанс уложиться в срок. Потому что главное во всей истории — укладываться в срок.
Использовать асинхронную запись не мешает ничто кроме риска потерять данные (если они критичны). Поэтому журнал транзакций в СУБД выполняется в синхронном режиме, и это влияет на производительность I/O. А логи веб-сервера могут вестись в асинхронном режиме (скорее всего, так и есть).
Кроме того, лог можно направлять в syslog и отправлять по сети на соседний сервер. Тоже выход.
А я имел ввиду ситуацию, когда и лог, и раздаваемый контент находятся на одном диске. Всё дело в количестве IOPs, а также в том, как именно nginx ведёт лог — синхронно или асинхронно (я не знаю этого наверняка, но, возможно кто-то другой здесь знает). Если синхронно, то любой запрос к статике — это, грубо говоря, 2 обращения к диску — на чтение целевого файла и на запись лога. Если асинхронный — то ситуация получше, запись кидается в очередь в оперативной памяти, а ОС сама записывает на диск когда ей удобнее.
С точки зрения производительности — лучше на другой физический диск на этом же сервере, с точки зрения безопасности — наверное Вы правы. Можно использовать syslog.
Строго говоря, логирование может сказаться на быстродействии, если дисковое I/O загружено под завязку, либо если объём логов слишком велик. В случае СУБД рекомендуется выносить лог транзакций на отдельный физический диск, хранящий исключительно лог. В этом случае скорость работы СУБД ограничится потоковой скоростью записи на диск (~100+ МБ/с). Полагаю, для Nginx как и для других логирующих систем этот принцип будет так же справедлив.
_надрачивать_ на одинарные кавычки — вредный совет
> А его ещё и в официальной документации дают
там дают совет «не забудьте, что в двойных кавычках происходит автозамена $-переменных на их значения», а вовсе не «одинарные кавычки быстрее двойных»
Вернёмся к нашим китайцам? Проблема для мелкомягких в том, что Китай неподконтролен остальному миру, в частности США. Конечно, Китай состоит в ВТО, и обязан соблюдать правила игры. Но в большой политике честность не всегда играет решающую роль, а Китай в экономическом смысле сильная держава.
В общем, китайцы пользуются интеллектуальными достижениями всего мира, и не только софтом, но и идеями вообще. Мелкомягкие не могут запретить китайцам использовать свой софт, потому что китайцы его уже используют. Всё что могут мелкомягкие — это снизить цены и сделать вид, будто делают китайцам одолжение. На самом деле это китайцы делают одолжение. Никаких административных гонений там не будет, потому что это Китай.
Я б предложил другой вопрос — продаю ли я труд других людей по себестоимости. Да, иногда даже себе в убыток. Что произойдёт, если повышать цену? Те люди, которым я делаю заказы, будут получать больше. Чем отличается такой подход от корпоративной жадности? Тем, что корпоративная жадность приводит к раздуванию бюрократического аппарата — 10 менеджеров на 1 программиста :)
Вы задали некорректный вопрос. Себестоимость труда не оценивается изнутри, её можно оценить только снаружи. Т.е. если я перепродаю труд другого человека — я могу сделать наценку или наоборот скидку, в этом случае себестоимость (исходная величина) — сколько я заплатил этому человеку. Если же я продаю свой труд — то во сколько бы я его ни оценил, сумма будет равна себестоимости.
Это не так. Им просто похуй.