Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <p>Предлагаем вашему вниманию несколько полезных советов. Они могут пригодиться тем, кто разрабатывает и поддерживает высоконагруженные системы.</p>

2 <h2>Совет № 1: помните, что сломаться может любой компонент</h2>

3 <p>Рано или поздно что-нибудь откажет, причём сломаться может всё - не забывайте об этом, когда проектируете высоконагруженную систему. А цитата из закона Мерфи должна висеть у вас на стене напротив рабочего места. Ведь<strong>если есть вероятность, что какая-нибудь неприятность может случиться, она обязательно произойдёт</strong>.</p>

4 <p>Ваша задача - подстелить соломку везде, где это возможно. Что имеется в виду: 1. Зеркалирование 100 % серверов баз данных. 2. Ежедневное резервное копирование. 3. Механизм round robin DNS для балансировки нагрузки. 4. Несколько серверов приложений обеспечит масштабирование и позволит обновлять их поочерёдно, не прерывая обслуживание. 5. Серверы доменных имён располагайте в разных корневых зонах сети. Например, .com, .net, .org, .ru. В результате вы получите дополнительный уровень надежности, ведь если вся доменная зона .ru будет по каким-либо причинам недоступна в DNS, клиенты всё равно смогут работать с вашим сервисом.</p>

5 <p>Также обратите внимание, что зеркала должны быть расположены не просто в разных дата-центрах, а в разных странах. Дело в том, что в дата-центрах систематически проводятся регламентные работы, а ваш сервис прерывать свою работу не должен. Вдобавок к этому, следует регулярно устанавливать обновления безопасности, что иногда требует перезагрузки. И горячее переключение на резервный сервер будет как нельзя кстати.</p>

6 <h2>Совет № 2: преждевременная оптимизация вредна</h2>

7 <p>Как правило, в процессе роста нагрузки приходится покупать память (RAM) и оптимизировать приложение. Но если у вас есть предположения, что нужно что-то ускорить, не спешите это делать, предварительно не выполнив точных замеров. Очень велика вероятность, что ваши предположения ошибочны. То есть вы не можете точно знать, где находится "узкое место" вашего приложения.</p>

8 <p>Как же понять, какая конкретно функция работает недостаточно быстро? Профайлер на боевом сервере? Можно, но слишком много накладных расходов, плюс сервис начинает тормозить. Сложно судить о проблемных местах и по синтетическим замерам в тестах на машине разработчика…</p>

9 <p>Как вариант -<strong>добавление в код контрольных точек</strong>и оценка скорости приложения по времени исполнения программы между этими точками. В результате вы сможете выяснить то, о чём и не предполагали. И создать решение, которое будет быстрее, чем у конкурентов на рынке.</p>

10 <h2>Совет № 3: тестируйте всё</h2>

11 <p>Необходимо тестировать все изменения, причём делать это следует на объёмах данных, которые максимально приближены к боевым. А запуск сотен автоматических тестов при каждой сборке приложения обеспечит отсутствие фатальных ошибок.</p>

12 <p>Представьте, что вам надо изменить структуру таблицы в БД. Такая процедура потребует остановки сервиса, поэтому выполнять её придётся в наименее нагруженное время - в выходные ночью. И скорость выполнения технических работ будет чрезвычайна важна. Естественно, вы сделали предварительные тесты на маленькой таблице, которые показали, что на процедуру уйдёт не более минуты. Однако остановив сервис и запустив процедуру на боевом сервере, вы обнаруживаете, что процедура не закончила свою работу ни через минуту, ни через десять, ни через час. А всё потому, что стал перестраиваться кластерный индекс в таблице большого объёма, чего не происходило в маленькой таблице.</p>

13 <h2>Совет № 4: обеспечьте высокую скорость тестирования</h2>

14 <p>Не жалейте денег на ресурсы для команды и приобретайте высокопроизводительные сервера для автоматизированных тестов, ведь их число постоянно растёт.</p>

15 <p>Несмотря на тестирование, иногда в релиз попадает ошибка. Да, никто не любит откатывать релизы, но в некоторых случаях без этого не обойтись. А исправления надо вносить очень быстро, чего можно достичь за счёт автосборки, автоматизированных тестов и распараллеливания. При медленном тестировании ошибки исправляются дольше со всеми вытекающими отсюда репутационными и финансовыми потерями.</p>

16 <h2>Совет № 5: должна использоваться каждая функция продукта</h2>

17 <p>Развитие требует жертв, а хороший продукт - многих итераций. Причём речь идёт не только о добавлении новых функций, но и об удалении старых и ненужных, т. к. они: - занимают лишнее место на экране; - потребляют ресурсы на поддержку; - не несут никакой ценности, ведь их не используют.</p>

18 <p>Как хороший садовник обрезает молодые побеги каждую весну, так и вы должны "обрезать" ненужную функциональность, формируя правильную, здоровую и красивую "крону дерева".</p>

19 <p>Да, кому-то это не понравится, ведь даже непопулярные фичи использует не менее 2 % пользователей. Но, как уже было сказано выше,<strong>развитие требует жертв</strong>. К тому же, всегда предоставляйте возможность сделать то же самое (быстрее и удобнее), но несколько по-другому. Правда, всё равно не все останутся довольны, ведь, к сожалению, привычки оказываются сильнее…</p>

20 <p><em>Статья подготовлена по материалам блога компании<a>Pyrus</a>.</em></p>