Без каких инструментов современному веб проекту будет не просто?
Для домашних проектов все эти рекомендации скорее оверхед чем польза, но чем серьезнее становится проект и аудитория - тем важнее эти советы и правила.
Никогда не забывайте делать резервные копии.
⁃ Бекап должен быть максимально полезным, а значит содержать в себе только те данные, которые заново воспроизвести будет не возможно или долго-дорого.
⁃ Бекап должен быть подтвержден тестами на работоспособность сохраненной копии данных.
⁃ Бекап должен быть эксплуатирован, развертка из бекапа должна проверяться с какой-то переодичностью
⁃ Бекап должен быть безопасным. В идеале зашифрован.
⁃ Используйте специальный софт, а не bash скриптики с кроном. (хотя это тоже работает до определенного момента), но лучше - https://habr.com/ru/company/flant/blog/420055/
⁃ Используйте несколько источников хранения бекапов. Бывает так, что одного может не оказаться в какой-то момент (не доверяйте слепо облакам).
Фиксируйте ошибки приложения проактивно.
⁃ Если приложение упало, вы можете об этом никогда не узнать, если не мониторите access логи сервера.
⁃ Если приложение работает не корректно у клиента, при этом это современное spa приложение, вы об этом не узнаете примерно никогда, если не настроите правильный мониторинг такого поведения (читай сбор ошибочного поведения со стороны фронтенда) или до тех пор пока к вам не придет сам пользователь с жалобой (нужно дать возможность сообщать о багах из веб морды).
⁃ Хорошим тоном и практикой является подключение публичной sentry для фиксации ошибок, например вот так можно начать - https://habr.com/ru/post/508686/
Мониторинг работы сервера и приложения.
⁃ Чем больше всего нужно, тем больше за этим нужно наблюдения, к сожалению.
⁃ Хорошим стартом будет базовый grafana + prometheus + экспортеры метрик для фиксации работы приложения, сервера и инфраструктурных слоев.
⁃ Если есть опыт и желание, можно обойтись zabbix.
⁃ Уведомление о том, что сервер сломался и(или) что-то подходит к пиковым характеристикам можно реализовать либо через туже grafana, либо через alertmanager.
⁃ Использования облачных grafana или других инструментов для сбора и анализа метрик тоже хорошая история, если вы им доверяете (!)
⁃ Логи кстати тоже надо мониторить, тут подойдут какие-нибудь graylog или loki, или еще что-то ибо решений прям очень много.
⁃ Ну и внутреннего мониторинга не достаточно, нужно проверять что приложение работает из вне. Для этого есть saas сервисы, ну или можно реализовать самостоятельно.
⬇️ Далее
Для домашних проектов все эти рекомендации скорее оверхед чем польза, но чем серьезнее становится проект и аудитория - тем важнее эти советы и правила.
Никогда не забывайте делать резервные копии.
⁃ Бекап должен быть максимально полезным, а значит содержать в себе только те данные, которые заново воспроизвести будет не возможно или долго-дорого.
⁃ Бекап должен быть подтвержден тестами на работоспособность сохраненной копии данных.
⁃ Бекап должен быть эксплуатирован, развертка из бекапа должна проверяться с какой-то переодичностью
⁃ Бекап должен быть безопасным. В идеале зашифрован.
⁃ Используйте специальный софт, а не bash скриптики с кроном. (хотя это тоже работает до определенного момента), но лучше - https://habr.com/ru/company/flant/blog/420055/
⁃ Используйте несколько источников хранения бекапов. Бывает так, что одного может не оказаться в какой-то момент (не доверяйте слепо облакам).
Фиксируйте ошибки приложения проактивно.
⁃ Если приложение упало, вы можете об этом никогда не узнать, если не мониторите access логи сервера.
⁃ Если приложение работает не корректно у клиента, при этом это современное spa приложение, вы об этом не узнаете примерно никогда, если не настроите правильный мониторинг такого поведения (читай сбор ошибочного поведения со стороны фронтенда) или до тех пор пока к вам не придет сам пользователь с жалобой (нужно дать возможность сообщать о багах из веб морды).
⁃ Хорошим тоном и практикой является подключение публичной sentry для фиксации ошибок, например вот так можно начать - https://habr.com/ru/post/508686/
Мониторинг работы сервера и приложения.
⁃ Чем больше всего нужно, тем больше за этим нужно наблюдения, к сожалению.
⁃ Хорошим стартом будет базовый grafana + prometheus + экспортеры метрик для фиксации работы приложения, сервера и инфраструктурных слоев.
⁃ Если есть опыт и желание, можно обойтись zabbix.
⁃ Уведомление о том, что сервер сломался и(или) что-то подходит к пиковым характеристикам можно реализовать либо через туже grafana, либо через alertmanager.
⁃ Использования облачных grafana или других инструментов для сбора и анализа метрик тоже хорошая история, если вы им доверяете (!)
⁃ Логи кстати тоже надо мониторить, тут подойдут какие-нибудь graylog или loki, или еще что-то ибо решений прям очень много.
⁃ Ну и внутреннего мониторинга не достаточно, нужно проверять что приложение работает из вне. Для этого есть saas сервисы, ну или можно реализовать самостоятельно.
⬇️ Далее