О проектах, отягощенных производительностью

Какие бывают системы
Высокая нагрузка:
- 100+К событий в секунду;
- Гигабиты трафика;
Корпоративные:
- 1000 событий в сутки;
- Сложнозапутанная бизнес – логика;
- Все ради надежности и удовлетворения заказчика.
Про базы данных
Insert быстрее update и гораздо лучше масштабируется;
Blobы иногда бывают полезны;
Длинные транзакции противопоказаны даже версионникам;
Генерация отчетов – не дело для оперативной системы;
БД должна быть простой.
Что нужно знать
Среднесуточную нагрузку;
Максимальную пиковую нагрузку;
Суточная/3600/24*П?
Цена потери транзакции;
Стоимость простоя сервиса;
Возможности технических перерывов;
Допустимые стоимости атаки
- DDOS;
- Криптография.
Асинхронная обработка
Не всегда можно успеть обработать все полученные события. Но часто достаточно их только получить, обработать можно и потом.
Обработка ошибок
Ошибки бывают:
- Пользовательские;
- Свои;
- Чужие;
- Устранимые силами пользователя;
- Неустранимые;
- Фатальные.
Мониторинг
Оперативные: Nagios, Zabbix.
Профилактический: статический анализ логов. Хотя бы ежедневный.
А теперь еще несколько банальностей о самом главном, о процессе Организация.
Главное при разработке
Кадры решают все. Любое архитектурное решение или сделанный выбо в первую очередь зависит от имеющихся людей.
Роли в команде
Системное администрирование;
Разработка БД;
Общение с заказчиком;
Общение с начальством;
Тестирование;
Удержание архитектурной рамки;
Интеграция;
И, наконец, разработчик.
Идеальная команда
Самостоятельность;
Здравый смысл;
Свободная коммуникация;
Делегирование ответственности и полномочий;
Взаимное доверие.
Какие нужны документы
Общее виденье проекта (vision);
Описание архитектуры;
Требования к системе;
Запросы на изменения;
Недельный план;
План итерации.
Быть самураем
Не бывает сервисов, которые не падают. Кому звонить при падении, нужно знать заранее. И описание действий по подъему сервиса лучше написать заранее.
Notebook и SkyLink стоят немного.
Если сисадмину часто звонят ночью – то точно нужен еще один сисадмин.
Код
Нужно уметь пользоваться системой контроля версий. KeepltSimpleStupid.
Лучше поставить еще один сервер, чем ломать голову, разбирая запутанный код.
Изобретая велосипед, задумайся, зачем?
А какие документы желательны
Коллекция наработанных best practics;
Всевозможные описания «how to» для популярных задач;
Список всех допущенных грязных хаков;
Пожелания по рефакторингу.
Инструменты
База знаний – Wki (Confluence);
Учет работ и ошибок – Jira, Bugzilla;
Оперативное планирование – ProjectCards, GreenHopper;
Контроль версий – Subversion.
Методологии
Каждому проекту – свою мотодологию.
Agile;
- Вряд ли XP, но вполне SCRUM
Рефакторинг;
Предвидеть на один шаг;
Сохранять общее представление.
Тестирование
Автоматическая сборка;
Покомпонентное автоматическое тестирование;
Интеграционное автоматическое тестирование;
Автоматическое нагрузочное тестирование.

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