Надежность сайта. Как повысить стабильность веб-проекта

Введение

Когда вы внесли последний штрих в свой сайт и готовы к его запуску, вы глубоко ошибаетесь - не бывает последнего штриха. Всегда можно что-то улучшить в плане надежности, визуальной привлекательности, понятности и ясности контента, производительности.

 Запуск сайта не отменяет процесс дальнейшего совершенствования сайта.

Более того, некоторые моменты по недоработкам могут быть выявлены только на поздних стадиях внедрения сайта. Простой пример - количество данных. При малом количестве данных сайт шустро обрабатывает информацию. Но как только данных стало побольше, все начинает тормозить. Виной тому зачастую бывают неоптимизированные sql запросы. На малых объемах они отлично отрабатывают, а при увеличении таблиц нужно больше памяти, и все начинает тормозить.

Сайт можно и нужно шлифовать.

Если вы играете в долгую, то вложения в сайт носят Кумулятивный эффект. Постепенно сайт становится все более и более привлекательным для целевой аудитории, более защищенным и надежным для достижения тех целей, ради которых он создавался. 

В этой статье мы коснемся вопроса, как постепенно улучшать свой сайт по различным направлениям. Все эти меры сложно (а некоторые и не нужно) учесть на ранних этапах разработки.

К примеру, некоторые заказчики хотят обязательно капчу, т.к. иначе боты замучают. Но в реальности для стартапа гораздо актуальнее и критичнее потеря конверсии регистрации, чем наплыв ботов.

 Мы рассмотрим следующие аспекты:

1. безопасность;
2. оптимизация быстродействия;
3. профилактика;
4. стабильность по мере добавления функционала сайта;
5. проработка рисков.

Как улучшить защищенность сайта

Безопасность можно разделить на 3 составляющие - конфиденциальность, доступность и целостность:

1. данные можно украсть (конфиденциальность),
2. данные можно сделать недоступными для пользователя (доступность),
3. данные можно потерять или нарушить (целостность)

 Что мы можем улучшить в плане безопасности своего сайта:

Делать бекапы

Регулярно создавать новые резервные копии и проверять периодически работоспособность копии.

Может сложиться такая ситуация, что копии делаются, но восстановить из них базу данных проблематично. Особенно это актуально, когда используется какая-то сложная модель инкрементального бекапа.

Как минимум делайте хотя бы 1 раз в неделю полный бекап базы и обязательно храните бекап на удаленном хранилище. Подключите dropbox для синхронизации хранилища архивов. В случае утраты сервера у вас будут бекапы в Dropbox.

Проработка типовых атак. Проверить сайт на надежность

Основные атаки - это XSS (внедрение скриптов и HTML через поля ввода и URL), SQL инъекции (попытки ввода sql через поля ввода в надежде обойти защиту), DOS (намеренная загрузка сайта большим количеством запросов, при котором он падает либо не может обрабатывать другие запросы).

Каждый тип атаки можно попробовать реализовать на своем сайте. Найти типовые векторы атаки на сайты и проработать их реализацию на своем сайте.

При этом CMS сайта только частично защищает вас. Система может быть очень защищенной, но какой в этом толк, если программист забыл вставить проверку доступа в каком-то месте или пароль администратора 123456.

Безопасность определяется наиболее уязвимым местом. Можно составить свой чек-лист базовой проверки безопасности и постепенно его углублять.

Также есть специальные сервисы, позволяющие выявлять некоторые проблемы безопасности через аудит. Пример - Detectify.

Карта рисков

Сайт работает в очень переменчивой среде - разные пользователи, разные типы соединений, разный уровень доступ у пользователей. Сайт может взаимодействовать с внешними системами, которые также добавляют нестабильность в общую картину.

Продумайте основные типы возможных проблем с сайтом. Не пренебрегайте самыми банальными проблемами.

Знаете самую вероятную причину остановки сайта (доступность)? Это не DOS атака. Это просто владелец забыл продлить хостинг, домен или DNS хостинг.

Необходимо на каждый риск иметь меры по снижению вероятности реализации риска, а также меры по снижению критичности риска (т.е. событие наступило, но это уже не смертельно для нас).

На практике про риски вообще мало кто задумывается. Это прерогатива владельца продукта, а не разработчиков. Учитывайте эту активность в своем проекте - создавайте свою карту рисков, и прорабатывайте меры их сглаживания.

Несколько рисков на поверхности:

1. Недоступность сервера - сервер просто не отвечает.
2. Атака на DNS - совсем недавно мы все узнали, что это такое.
3. Потеря пароля - придумайте свое хранилище паролей. Самый простой вариант - локальная Excel таблица в архиве с паролем.
4. Потеря бекапа - дважды видел ситуацию, когда не было свежего бекапа на проектах.                               

Важно держать нужные контакты под рукой - это разработчики, администраторы сервера, хостер-компания, сеошники, ведущие проект и др.

Дублируйте функции администрирования - на случай если человек недоступен.

Имейте хотя бы минимальный инструментарий для самостоятельных действий с сайтом - перезагрузить, поменять DNS, написать в тех поддержку.

Ревизия кода в плане корректности доступов

Код проекта необходимо шлифовать и улучшать. На это не хотят особо тратить бюджет заказчики по причине того, что это должно и так быть идеально с первого раза (такое убеждение часто встречается). На это не хотят особо тратить время  программисты, т.к. и так хватает задач по доработкам в проекте. А между тем эта работа упрощает будущее развитие системы, а также позволяет найти некоторые проблемы, которые могут быть выявлены только через инцидент.

Нужно как минимум проводить аудит кода в плане мелких шлифовок (стили, анализ выполнения, поиск очевидных неточностей). А как максимум - делать глубокий рефакторинг по необходимости.

При рефакторинге встает другая проблема. Страшно менять работающую систему - можно что-то поменять, и оно станет работать неверно. Эта работа требует особой аккуратности и ответственности.  А также готовности быстро вернуть предыдущий вариант или исправить возникшую ошибку. Подобные правки требуют активного участия тестера.

Отслеживание опасных событий

У нас есть специальная таблица trace куда падают записи об особых событиях, происходящих в системе. Это не обязательно связано с безопасностью. Это просто некоторые аномалии, которые происходят в системе. Что это может быть: дублирование запросов с клиента, слишком большая выдача данных, факт блокировки IP, неверно введенный пароль.

Периодический анализ подобных событий позволит своевременно выявить проблему и заняться ее решением.     

Также вы можете создать некий механизм, который сам по определенным правилам будет анализировать события и дергать вас, когда это необходимо.

Защита от ботов

Боты могут создавать проблемы доступности сервиса, а также копировать ваш контент (например, каталог товаров).

Необходимо распознавать слишком активных ботов и блокировать их. Например, в нашей платформе есть механизм, позволяющий фиксировать такую активность и блокировать такие IP на некоторое время.

Тут конечно важно не переборщить. Вы можете случайно заблокировать хороших ботов (например, Яндекса и Гугла).

Важно не делать пороги аномальной активности слишком низкими, иначе легитимные пользователи могут начать получать отказ в доступе.

Если вашу форму начинают пробивать боты (т.е. происходят фиктивные заполнения форм), то имеет смысл рассмотреть вариант использования капчи. Это усложнит беззаботную жизнь ботов. Но также усложнит и работу пользователей на сайте. Сами решайте, насколько критично 2-4 левых заявки от ботов в неделю на почте.

SSL                     

Простая и стандартная защита трафика от посторонних глаз.

По умолчанию http трафик не шифруется. Т.е. промежуточные узлы (например, злоумышленник на Wifi точке) могут увидеть данные, которые передаются между браузером и сервером.

При использовании https соединения браузер и сервер договариваются использовать шифрование через сессионные ключи. Т.е. трафик между ними могут прочитать только они. А промежуточные узлы видят только абракадабру.

Сейчас SSL это обязательный элемент для любого сайта, т.к. браузеры выдают окна предупреждения при посещении сайтов без защищенного соединения.

Как оптимизировать быстродействие сайта

Рано или поздно абсолютно любое будет тормозить (если его не обслуживать): данные растут, сервер забивается, посещаемость может вырасти. Самый дурацкий довод по этой теме - "ведь раньше же нормально работало".

Сайт работает в очень переменчивой среде - меняется база, загружаются файлы, меняется объем трафика, появляются злоумышленники, которые находят слабые места, вносятся изменения в сайт.

Нужно постоянно отслеживать состояние приложения и выявлять проблемные места, мешающие нормальному быстродействию системы.

В этом разделе рассмотрим некоторые моменты, которые позволят улучшить быстродействие сайта.

Откажитесь от тяжелых решений

Если вы будете следовать этому принципу, вероятно у вас никогда не возникнет больших проблем с быстродействием.

Если что-то медленно работает - это не должно быть частью вашего сайта.

Просто не допускайте их наличия в сайте. Медленно работает - значит убираем с сайта эту страницу. Также помните, что любой модуль можно реструктурировать и он будет работать проще и лучше.

Например, вы выводите все заказы и товары к ним сразу на странице. Т.е. некие сущности и вложенные данные (товары). Как можно улучшить вывод? Необходимо выводить только заказы при первой загрузке. А товары подгружать по клику на ссылку в подтаблице. Это значительно улучшит быстродействие страницы на больших данных. 

Имейте запас по ресурсам, не должен сайт работать на пределе. Нужно упрощать

Если у вас есть медленная страница и она более-менее работает (загружается 5 сек), то учитывайте это проблемное место, которое в будущем потребует больше ресурсов. Будьте готовы упростить эту страницу, отказаться от какого-то проблемного фильтра. С ростом данных подобные проблемы будут еще острее.

Самое правильное решение - реструктурировать эту страницу сразу, а не ждать, когда все будет просто падать.

Самое неприятное в медленном функционале - он сам медленно работает, но еще тянет и всю систему вниз.

Обычно медленный функционал стягивает на себя множество ресурсов, что может ухудшить работу системы в целом. Поэтому, имея в своей системе 3-5 подобных мест, может возникнуть проблема периодической нехватки ресурсов. 

Ищите постоянно медленные места и решайте их сейчас, а не когда уже начались тормоза всей системы в целом.    

Не вываливайте на пользователя очень много информации за 1 раз

Некоторые пользователи любят на манер Excel сразу смотреть 200 строк таблицу. В целом это порочная практика. Нужно правильно использовать фильтры. Задействуйте 2-3 фильтра и получите 20-30 ключевых строк и работайте с ними. Вы все равно на экране не можете уместить сразу более 20 строк. И все бы ничего, если это просто 200 строк обычных данных, но ведь там могут быть и агрегированные данные. Одно дело получить данные для 20 строк, а другое 200.

В итоге чем больше строк мы выдаем за 1 раз, тем больше требуется ресурсов сервера, и тем дольше выполняется запрос.

Если ваша таблица медленно грузится - первым делом уменьшите размер пагинации до разумных пределов.

Чистка базы данных, сервера

Каждое посещение пользователя оставляет о себе следы на сервере - на диске и в базе данных. Большая часть этих данных  - это логи, журналы событий и т.д. Все эти данные копятся в системе. Их нужно периодически чистить.

Что именно чистить и как чистить - это бизнес-решение.

На одном проекте видел логовые данные более 60 млн записей. Конечно же такая таблица будет требовать кучу памяти при выполнении запросов к ней. Если данные не нужны - их обязательно надо чистить.

Также неплохой вариант - это хранение логовых данных в отдельной базе. Это упростит создание бекапа основной базы данных.

Место на диске сервера - конечная величина. Когда на сервере становится 0 байт, это приводит к проблемам производительности, некоторые функции сайта перестают работать (например, загрузка файлов). 

Отслеживайте место на диске и вовремя его чистите (либо расширяйте).

Более подробно о проблеме быстродействия читайте в нашей статье Как создать быстрый сайт

Проведение профилактики по сайту

Хорошей идеей будет сделать для сайта небольшую инструкцию по проведению профилактики сайта.

Профилактика - это ряд мер, направленных на снижение вероятности сбоев или возникновения проблем при эксплуатации сайта.

Здесь мы определим ряд подобных мер:

Периодическое тестирование, чек лист обхода сайта 

Проверяйте регулярно критичные места - регистрация, система оплаты и т.д.

В целом, за возможными проблемами можно следить косвенно по аналитике - если есть провал в данных, то возможно там возникла какая-то проблема и необходимо ее решать.

Но все же не помешает глазами пробежаться по основному функционалу. Это также помогает шлифовать продукт - выявляются мелкие недочеты, приходят новые идеи что улучшить.

Также имеет смысл создать вспомогательный чек-лист проверки. Он необязательно должен быть строгим чек-листом, где указаны дотошно все действия и ожидаемые результаты. Лучше формулировать его в терминах задач пользователя, т.е. хочу сделать то-то, получить то-то.

Так проверяющий не будет жестко привязан к лыжне и будет тестировать более широкий спектр моментов по работе сайта.

Отслеживание ошибок

Должен быть некий механизм просмотра всех ошибок. В идеале сделать так, чтобы вся подобная информация была собрана в одном месте.

Важно обеспечить проверяющего возможностью отделать критичные ошибки от мелких. Иначе есть риск, что за большим количеством мелких ошибок можно не заметить фатальные ошибки.

Если идет период внедрения, то ошибок будет больше нежели в более поздних стадиях. Т.е. на стадии тестирования их много, на стадии внедрения они также встречаются регулярно, а на стадии зрелой эксплуатации их должно быть минимальное количество. Это значит, что в первое время надо плотно следить за ошибками, затем можно постепенно уменьшать затраты на мониторинг ошибок.

Конечно, есть люди, которые скажут, что надо смотреть день и ночь за ошибками, не отрывая глаз от монитора. Ведь это же критично, это ошибки. Но на практике ваши ресурсы сильно ограничены - необходимо ими экономно управлять.

Подход "Все и сразу, и очень качественно" на практике не работает.

Вы просто сожжете ресурсы проекта на несущественные задачи и бюджет закончится до того времени, как проект начнет давать отдачу. 

Итак, на стадии запуска плотно смотрим за ошибками и постепенно ослабляем контроль по мере уменьшения количества возникающих траблов.

Также активнее следите за ошибками при частых изменениях в код проекта. Если вы перерабатываете какой-то модуль, велика вероятность, что возникнут новые ошибки.

Анализ трассировки

Трассировка в нашем случае - это просмотр событий на базе. Это таблица trace, к которой фиксируются ключевые моменты по активности сайта.

Выявляйте возможные проблемные события на ранних стадиях и принимайте меры по ним. Это надо делать регулярно, даже если никаких аномальных событий не происходит. Сейчас их нет, а через неделю они вполне могут появиться.

Используйте статистику для выявления аномалий. Создайте свой алгоритм выявления проблемных ситуаций. Система может регулярно проверять состояние таблицы трассировки по определенным бизнес-правилами и выдавать вам уведомление о текущем состоянии. Таким образом, вы можете автоматизировать процесс распознавания проблем. 

Совсем идеальный вариант - система сама распознает ситуацию и решает проблему.       

Использование метрики - проценты отказов на устройствах, Гугл показатели качества страниц

Использование инструментов поисковиков, веб-аналитики позволяет выявлять проблемные места.

Самое просто - это отчеты по устройствам в Яндекс.Метрике. Если у вас стандартный показатель отказов 15%, а на iphone 45%, то наверно что-то там не так (ну или ваш сайт посвящен поклонению Android). 

Также используйте Яндекс Вебмастер и Гугл Вебмастер. Показатели качества сайта и адаптации под мобильные подскажут, где что можно усовершенствовать, а также улучшат сайт в глазах поисковиков (т.е. плюс к поисковому продвижению).

Сегодня может быть все хорошо, а завтра ваш контент-менеджер загрузил на важную страницу фотку в 3Мб и показатели по этой странице сразу рухнут (особенно для мобильных). Поэтому раз в месяц можно туда поглядывать для выявления проблемных страниц.

Как улучшить стабильность работы сайта в плане развития сайта

Сайт постепенно развивается, добавляются новые элементы, удаляются неактуальные блоки, шлифуются отдельные возможности.

Любые изменения в системе уменьшают стабильность системы.

Загрузили файл на сайт - может сказаться на быстродействии страницы или ее выводе. Поменяли настройку - это может сказаться на каких-то аспектах работы сайта. Внесли изменения в код страницы - может возникнуть баг, и страница перестает работать. Внесли изменения в код глобальной процедуры - вообще можно положить весь сайт.  Просто помните, изменения идут рука об руку с возможными коллизиями и уменьшают стабильность.

Здесь рассмотрим несколько принципов, которые мы используем на практике при разработке платформы Falcon Space.

Все, что внедряем можно отключать без влияния на старые модули

Важно иметь возможность отключить новинки. Прямо в горячем режиме без перекомпиляции.

Конечно некоторые скажут: "Сейчас мы откатим версию в Git, и все будет как раньше". Но лучше разработать новую возможность так, чтобы ее полностью отключить через настройки.

Т.е. любая новая возможность в отключенном состоянии не должна никак влиять на старый функционал.

В случае проблем просто спокойно отключаем функционал через настройки и разбираемся что к чему.

Плотное логирование и особый контроль связей между подсистемами

Должна быть возможность логировать активность компонента, чтобы подсмотреть, как внутри работает компонент, и все ли данные верно обрабатываются.

В нормальном состоянии логирование может быть отключено. Но если есть проблемы - включаем логирование и изучаем, что там происходит внутри.

Если мы связываемся с внешней системой по API, то хорошо бы логировать все запросы - это позволит определить на какой стороне ошибка. Чем больше интеграций, тем меньше надежность. Ваша система может верно работать, а внешняя некорректно обрабатывать данные. Чтобы это понять, надо фиксировать, что мы передает вовне и что получаем от внешнего сервиса.

Пересмотр подхода к доработкам и развитию проекта в сторону простоты и надежности

Ставьте во главу угла не технологичность, следование трендам и излишне изысканные запросы пользователей, а надежность, скорость работы и простоту развития решения.

Если какой-то компонент сложно развивать, он иногда сбоит, и он в целом работает как черный ящик с постоянными фокусами - лучше вообще убрать такой компонент из системы. Дело в том, что чем больше таких компонентов с фокусами в системе, тем выше риск нестабильности.

Система и так будет постепенно усложняться, компоненты могут начать конфликтовать между собой, на каких-то устройствах они будут работать не так как надо. Поэтому все нестабильные, непрозрачные компоненты надо сразу убирать.

Хорошая идея - делать компоненты обертки вокруг внешнего плагина.

Так вы, по крайней мере, сможете заменить его относительно безболезненно в будущем в случае, если возникнут с ним непреодолимые проблемы.

Все ненадежные элементы должны быть отключаемые

В идеале вообще не должно быть ненадежных элементов. Но некоторые возможности очень нужно иметь в проекте (например, работа signalR для отправки сообщений с сервера на клиента).

Посмотрите на свою систему и определите, где у вас есть такие элементы. Представьте, что они начали кардинально сбоить. Если есть возможность их отключить, то это уменьшает риск всего проекта. Ведь может случиться так, что какая-то не очень важная возможность просто приводит к падению всего сайта.

В нашем случае такой возможностью была интеграция с телеграм. Что-то там не так работало и постоянно выдавало исключения, приложение падало.

Если у вас есть иструментарий отключения возможностей, вы можете быстро последовательно отключить возможности и найти этот проблемный модуль. При этом сайт довольно быстро восстановится и будет просто работать без этой возможности.

А если у вас нет отключения отдельных модулей, которые могут создать нестабильность, тогда гораздо сложнее искать проблемный элемент (в логах сервера), а самое неприятное - нельзя быстро вернуть работоспособность сайта (либо откатить на более стабильную версию, что может быть более плохим вариантом).

Заключение

Здесь мы описали свое видение как в идеале надо бы обслуживать проект. На практике все упирается в ресурсы, приоритеты, убеждение владельца продукта и желание срезать углы. Важно просто знать, что есть меры, которые мы описали в статье, зачем они нужны и что дают проекту. А дальше уже решение владельца продукта - что делать, а что можно пропустить.

Это все та же самая работа с рисками - какие-то риски требуют активности, а какие-то риски вам просто нужно принять как есть. Самое тупое, что бывает - "а я про это даже и не знал". Т.е. ситуация, когда про данный риск владелец продукта вообще ничего не знал изначально. Именно для этого мы и пишем подобные статьи - вскрыть различные проблемы и показать возможные решения.

Итеративно пробуйте внедрять активности, описанные в статье, и тем самым вы постепенно повысите надежность работы сайта.

Источник: https://falconspace.ru/blog/kak-povysit-nadezhnost-sayta