Comments 37
Всё, кроме, пожалуй, 26 пункта — плюсую. Спасибо, утащил в сокровищницу!
Да, 26-й пункт стоит однозначно убрать.
Или добавить пояснение. Я могу представить такие ситуации, в которых этот пункт справедлив.
Единственное оправданное применение «копипасты» — это одноразовый скрипт, который перестает быть полезен и удаляется сразу после использования. Но это как-то выходит за рамки темы «Чему мы научились, разрабатывая backend»…
Могу добавить пример: если у вас появилась в двух местах кода копипаста, это плохо, но он неё как правило можно избавиться множеством способов, которые потом усложнят её использовать в третьем месте. А вот как только эта копипаста расползлась по 3-4 местам, тогда можно убивать её более спокойно. Обычно ведь под копипастой имеется ввиду не абсолютно идентичные копии кода, а чуть-чуть отличающиеся. Обобщить слишком рано — усложнить доделки потом.
Аналогия: убивать копипасту слишком ранр — это как при появлении температуры тут же принимать жаропонижающее, вместо того, что бы изучить причины. Но и обратно, есть ситуации когда сбивать температуру нужно сразу, иначе пациент не доживёт до этапа анализа. (да, я только что из больницы :-( ).
Аналогия: убивать копипасту слишком ранр — это как при появлении температуры тут же принимать жаропонижающее, вместо того, что бы изучить причины. Но и обратно, есть ситуации когда сбивать температуру нужно сразу, иначе пациент не доживёт до этапа анализа. (да, я только что из больницы :-( ).
Мне кажется, вы приравниваете копипасту к преждевременной оптимизации. Вот последняя — да, на раннем этапе ни к чему хорошему не приведёт. А копипаста — совсем другое дело. Её главное опасное свойство — неконтролируемое размножение. Где есть 3 копипасты и «всё работает», тут же возникает желание добавить еще парочку, ну работает же, подумаешь, скопирую еще разок и всё, и рабочий день на полчасика короче… А потом люди боятся рефакторить чужой код (а некоторые и свой), т.к. боятся что-то испортить. В итоге со временем рефакторинг становится практически невозможным.
В общем, на мой взгляд преждевременная оптимизация и копипаста (или плохой дизайн) — это совсем не одно и то же.
В общем, на мой взгляд преждевременная оптимизация и копипаста (или плохой дизайн) — это совсем не одно и то же.
Единственное оправданное применение копипасты — красные тесты.
Прежде, чем добавлять какой-то уровень абстракции, хорошо бы получить работающий (и покрытый тестами) Proof of Concept, а уже после, видя более-менее полную картину, избавляться от нее более осознанно, чем в самом начале.
Какой хороший конспект, спасибо.
За пункты 5-6 не удержалась и вбросила ссыль на эту статью моим коллегам-разработчикам из-за которых мы уже год компостируем себе мозги изучаем на живом проекте OrientDB и Kafka. Там сейчас такое началось… :)
Поясните п.1. Не очень понятна ситуация и пути выхода.
Например: есть у вас myapp.myhost.com с которого nginx тянет статику и на котором живет backend API, используемое отображаемой страницой. Далее вы разрабатываете внутренний сервис, который использует вышеупомянутое API и из нежелания усложнять конфигурацию/пинать админов/и т.д. для вызовов используете адрес myapp.myhost.com. В час Х на перед доменом ставят CDN для ускорения загрузки страниц и все, что обращается на myapp.myhost.com начинает ходить через CDN со всеми вытекающими отсюда спецэффектами. По нашему мнению, самый простой вариант не создавать проблему — завести что-то типа origin.myapp.myhost.com и внутренние сервисы направлять на этот адрес.
Я бы всё же порекомендовал для внутренних сервисов получение адреса реализовывать через специальные тулзы для сервис дискавери вроде consul.
Сходу, пару ситуаций:
1. Вы хотите послать запрос к приложению, а он приходит на CDN и не доходит до бекенда.
2. CDN начнет обновляться с CDN. Эпичность последствий, я думаю, вы можете вообразить.
1. Вы хотите послать запрос к приложению, а он приходит на CDN и не доходит до бекенда.
2. CDN начнет обновляться с CDN. Эпичность последствий, я думаю, вы можете вообразить.
Linux-сисадмины скажут спасибо, если конфиги будут в /etc/myapp, логи в /var/log/myapp и т.д. Другими словами, храните файлы в общепринятых для OS директориях.
Любой лог-файл потенциально может бесконтрольно вырасти. На стадии проектирования планируйте жизненный цикл лог-файлов и данных, которые они содержат.
Мне кажется, в качестве еще более интересной практики можно продвигать использование уже готовых инструментов для сбора/записи/маршрутизации логов (начать можно просто с записи в syslog) — тогда сисадмины сами выберут, куда им складывать файлы (если вообще записывать логи в текстовые файлы), а разработчикам не придется в который раз изобретать ротацию и, возможно, инструменты для работы с самими логами.
Логи своих приложений — это пограничная зона ответственности. Когда удается договориться с админами — они ими рулят используя стандартные средства, когда нет — приходится познавать дзен.
Позвольте вставить свои 5 копеек как сисадмин: есть такая штуковина как FHS и PREFIX
FHS (Filesystem Hierarchy Standard) описывает что и куда складывать.
PREFIX — обычно передается configure-скрипту, чтобы указать кда положить всё дерево директорий, прописанное FHS.
Что это дает в сумме?
Вот вы ставите, скажем, nginx 1.9.5. По FHS он должен попасть в /usr/local, указываете ./configure --prefix=/usr/local и вуаля — он в /usr/local, логи в /usr/local/var/log и так далее.
prefix=/ только для того что ставится из пакетов (будь то deb, rpm или еще что).
С другой стороны, вы можете скачать свои сорцы в /usr/local/src/myapp собрать там и сделать checkinstall -D (или для rpm ключик заюзать) и ваша софтина теперь имеет право встать в /, а не в /usr/local. И сносится она легко — dpkg -r myapp
По логам — лично я считаю что лучше в syslog не писать. Пишите в $PREFIX/var/log/myapp/$instance.log, а админы уже прикрутят туда logcheck/logrotate, НО это лично моё мнение и я пока не рулил массово облаками, на уровне руления облаком всё может быть иначе (сбор логов, все дела).
FHS (Filesystem Hierarchy Standard) описывает что и куда складывать.
PREFIX — обычно передается configure-скрипту, чтобы указать кда положить всё дерево директорий, прописанное FHS.
Что это дает в сумме?
Вот вы ставите, скажем, nginx 1.9.5. По FHS он должен попасть в /usr/local, указываете ./configure --prefix=/usr/local и вуаля — он в /usr/local, логи в /usr/local/var/log и так далее.
prefix=/ только для того что ставится из пакетов (будь то deb, rpm или еще что).
С другой стороны, вы можете скачать свои сорцы в /usr/local/src/myapp собрать там и сделать checkinstall -D (или для rpm ключик заюзать) и ваша софтина теперь имеет право встать в /, а не в /usr/local. И сносится она легко — dpkg -r myapp
По логам — лично я считаю что лучше в syslog не писать. Пишите в $PREFIX/var/log/myapp/$instance.log, а админы уже прикрутят туда logcheck/logrotate, НО это лично моё мнение и я пока не рулил массово облаками, на уровне руления облаком всё может быть иначе (сбор логов, все дела).
По логам — лично я считаю что лучше в syslog не писать.Почему, если не секрет?
Пишите в $PREFIX/var/log/myapp/$instance.logНе забывайте, что access_log на 300 rps — это 300 записей на диск в секунду.
Почему, если не секрет?
С одной стороны, когда всё в одном месте — проще смотреть что происходило вообще.
На практике же syslog становится такой мусоркой, что без grep'а его смотреть невозможно.
Возможно с приходом systemd/journald и возможностью выбора что смотрет будет легче, но в продакшене Ubuntu 14.04, которая этого лишена напрочь.
Не забывайте, что access_log на 300 rps — это 300 записей на диск в секунду.
Опять-таки, зависит от того что вы пишете, чем и куда.
Например, в nginx можно не писать запросы на получение статики, а всё остальное писать через буфер — и вот 300 rps уже совсем не 300 wps.
С другой стороны, можно начать выдумывать костыли из разряда записи на отдельный диск (или сервер, особые извращенцы могут писать на tmpfs с ротацией лога по размеру в постоянное хранилище).
Да и симлинки никто не отменял — сделайте приложению симлинк в удобное вам место и пускай себе пишет.
Для nginx — да, но мы тут больше говорим про приложения собственной разработки.
syslog — очень гибкая система, которая не ограничивается записью логов в /var/log/messages.
syslog позволяет:
— иметь отдельные правила для каждого приложения
— передать логи по сети на отдельный log сервер;
— сохранять их по папочкам, в зависимости от имени хоста и приложения.
Например:
/$host/$service/$day.log
Помнится, я даже делал разделение по дням и часам:
/$host/$service/$year/$month/$day/$hour.log
В современных дистрибутивах давно стоят rsyslogd и syslog-ng, которые это умеют.
syslog — очень гибкая система, которая не ограничивается записью логов в /var/log/messages.
syslog позволяет:
— иметь отдельные правила для каждого приложения
— передать логи по сети на отдельный log сервер;
— сохранять их по папочкам, в зависимости от имени хоста и приложения.
Например:
/$host/$service/$day.log
Помнится, я даже делал разделение по дням и часам:
/$host/$service/$year/$month/$day/$hour.log
В современных дистрибутивах давно стоят rsyslogd и syslog-ng, которые это умеют.
Я как-то не задумывался над этим.
В таком случае да, вы правы.
В таком случае да, вы правы.
Мы тоже прошли похожий путь размышлений и в итоге в некоторых компонентах сделали управляемый извне уровень логгирования. По умолчанию в логи пишем только критические ошибки, но из админки можно переключить на более детальный, что позволяет более подробно изучать проблему не забивая попусту диск. Цена вопроса — изучение в деталях log4j и 100 строк кода
Log4j2 умеет это из коробки через JMX.
Пока для хранения и обработки дат можно использовать unix timestamp, лучше использовать unix timestamp.
Сомнительный совет как по мне.
Спасибо! Отличный список. Особенно пункт 8!
UFO just landed and posted this here
Как правило постоянны те запросы, которые написаны вручную. Если общение идет через ORM + проект развивается и местами рефакторится, то за полетом фантазии в составлении SQL запросов на всех уровнях не уследишь. А проблемными как правило оказываются единицы.
Я бы сказал так: включайте все slow-log'и, пока это не приводит к существенной деградации.
В одном случае у нас при включении slow-log'а крашились воркеры FPM, в другой — я открыл глаза разработчику на причину необъяснимых тормозов сайта (раз из пяти TTFB >5 секунд, причем проблема явно где-то коде сайта).
В одном случае у нас при включении slow-log'а крашились воркеры FPM, в другой — я открыл глаза разработчику на причину необъяснимых тормозов сайта (раз из пяти TTFB >5 секунд, причем проблема явно где-то коде сайта).
Как правило, log slow queries имеют настраиваемый порог срабатывания, можно добиться логирования только действительно аномально медленных запросов. А если он может устанавливаться на уровне сессии, то настраивать логирование можно хоть на уровне отдельных запросов: этот запрос логировать, если выполняется больше секунды, а этот — если больше 3-х часов.
Linux-сисадмины скажут спасибо, если конфиги будут в /etc/myapp, логи в /var/log/myapp и т.д.
Не факт. Некоторые предпочитают, чтобы приложение лежало в одном каталоге. Особенно когда действует принцип «один-сервер — одно приложение».
Это уже обсуждалось, выше: habrahabr.ru/company/parallels/blog/269927/#comment_8637989
Sign up to leave a comment.
Чему мы научились, разрабатывая backend