Многие растущие стартапы могут не осознавать, что их сервисы находятся на грани падения, и только чудо спасает их от позора. Ниже приведены мысли вслух по поводу типовых ошибок начинающих стартапщиков, которые каким-то образом смогли выложить своё детище на всеобщее обозрение.
- Веб-сервис (подразумевается любая онлайн-система, необязательно WSDL интерфейс), работающий на одном сервере, - нонсенс. Что будет, если этот сервер скончается? Ты не выставляешь наружу веб-приложение, работающее на одном ноутбуке, так почему ты используешь один сервер? Независимо от того, сколько инвесторы вложили в твой бизнес (и если они хоть что-то вложили), система, работающая на одном компьютере, - это хобби, а не бизнес. Минимально допустимая конфигурация - это два веб-сервера и сервер БД с репликацией master-slave.
- Дизайн сети - это не то, как сервера соединяются с интернетом. Компьютерная сеть требует ощутимо больше внимания, чем электрическая сеть. К сожалению, существует не так много стартапов, инвестирующих в балансировщики наагрузки, отслеживающие отсутствие отклика от сервера, а не просто поочерёдно кидая запросы то на один сервер, то на другой. Дополнительным плюсом балансировщиков является то, что если один из серверов тихо скончается, пользователи системы, возможно, заметят ухудшение работы сервиса, но сам сервис будет работать. В это время специалист может вернуть упавшее железо к жизни и снова ввести его в строй. Необязательно инвестироваться в супер-дорогое железо: бывшие в употреблении балансировщики нагрузки продаются на eBay, или их могут привезти на заказ из стран ближнего зарубежья. Нет недостатка и в сетевых инженерах, пары-тройки дней работы в квартал которых вполне будет достаточно для того, чтобы на минимальном уровне защитить сервис от падения или ощутимого ухудшения работы по причине сбоящего оборудования. (Их советы можно перепроверить у знакомых, уже сталкивающихся с подобными проблемами.)
- Купи себе Blackberry или иной телефон с быстрым почтовым клиентом (мне нравился Nokia 9300). Зарегистрируйся в службе по мониторингу серверов - причём, тебя должно интересовать не полное прекращение работы, а также замедление отклика (что свидетельствует о пиковой нагрузке). Задумайся об установке и конфигурации мониторинговой станции на базе, например, Nagios. Количество людей, уходящих в походы, уезжающих куда-то или иным способом делающих себя недоступными, а потом возвращающихся в офис, чтобы узнать, что их сервис пару дней был полностью недоступным, очень велико. (Кстати, на Nokia 9300 я активно использовал Putty, так что я мог рулить серверами из любой точки света.) Нет денег на телефон с серьёзным почтовым клиентом? Купи пейджер, обслуживание которого тебе будет стоить копейки, но который даст тебе возможность знать, если стряслась беда.
- Успех - не отмазка. Да, тебе может повезти, и твой сервис будет очень популярным. Да, ты будешь объяснять медленную скорость работы своего единственного сервера тем, что на сайте много пользователей. Так сделай что-нибудь! Пользователи очень быстро устают от медленных сайтов - даже популярных.
- Минимизируй зависимость от базы данных. Из моего опыта, больше половины всех проблем, встречающихся с онлайн-системами, связано с работой с базой данных: недостаточное количество соединений в пуле, ошибки в драйверах, медленные запросы. Никто не говорит, что база данных - это зло. Просто это дополнительное звено, делающее сервис менее надёжным. Как быстро может сервис переключиться на копию базы, если основной сервер впадёт в кому? Можно ли не писать данные в базу в режиме реального времени - особенно в часы пиковой нагрузки? (Лучше данные будут не самой первой свежести, но весь сервис будет работать.)
- Любой ценой избегай долгоиграющих процессов. (Взаимосвязь между возможными потерями памяти и большим временем исполнения больших запросов давно известна.)
- Кто-то должен быть ответственным за бесперебойность функционирования сервиса. Над продуктом или сервисом может работать десяток человек, но если все ответственные за продукт - никто за него на самом деле не ответственный. Причём, это необязательно должен быть программист или системный администратор. Это может быть человек, который может быстро решить проблему - сам или посредством нескольких звонков нужным коллегам. У каждого продукта или сервиса должен быть такой ответственный человек (В Mobile Messenger такой человек я - для всех полутора десятков продуктов сразу).
Список, разумеется, неполный, но может дать представление начинающим основателям, куда смотреть, если они хотят увидеть свой сервис быстро развивающимся и надёжным.
Оригинал находится вот тут.
