Жизненный цикл веб ресурсов

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РЕСПУБЛИКИ БЕЛАРУСЬ

БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ИСТОРИЧЕСКИЙ ФАКУЛЬТЕТ

Реферат на тему «Этапы жизненного цикла web – ресурса»

Выполнила студентка 4 курса,

7 группы, заочной формы обучения

Специальность: музейное дело

Бурдильная Дарья Игоревна

Минск, 2012

Содержание

Введение………………………………………………………………………………………………………………………. 3

Этапы жизненного цикла web – ресурса………………………………………………………………………… 5

Заключение…………………………………………………………………………………………………………………. 11

Список использованной литературы……………………………………………………………………………. 13

Введение

Сайт (от англ. website: web – «паутина, сеть» и site – «место», буквально «место, сегмент, часть в сети») – совокупность электронных документов (файлов) частного лица или организации в компьютерной сети, объединённых под одним адресом (доменным именем или IP-адресом). Все сайты в совокупности составляют Всемирную паутину, где коммуникация (паутина) объединяет сегменты информации мирового сообщества в единое целое – базу данных и коммуникации планетарного масштаба. Для прямого доступа клиентов к сайтам на серверах был специально разработан протокол HTTP. Web-сайт (сайт) – это совокупность Web-страниц, доступных в интернете через протоколы HTTP/HTTPS. По структуре сайт – это набор страниц, по сути – совокупность текстовой и графической информации, логически связанной между собой, и способов ее представления. Первый в мире сайт .cern.ch появился в 1990 году. Его создатель, Тим Бернерс-Ли, опубликовал на нём описание новой технологии World Wide Web, основанной на протоколе передачи данных HTTP, системе адресации URI и языке гипертекстовой разметки HTML. Также на сайте были описаны принципы установки и работы серверов и браузеров. Сайт стал и первым в мире интернет-каталогом, так как позже Тим Бернерс-Ли разместил на нём список ссылок на другие сайты. Все инструменты, необходимые для работы первого сайта, Бернерс-Ли подготовил ещё раньше – в конце 1990 года появились первый гипертекстовый браузер WorldWideWeb с функционалом веб-редактора, первый сервер на базе NeXTcube и первые веб-страницы.

«Отец» веба считал, что гипертекст может служить основой для сетей обмена данными, и ему удалось претворить свою идею в жизнь. Ещё в 1980 году Тим Бернерс-Ли создал гипертекстовое программное обеспечение Enquire, использующее для хранения данных случайные ассоциации. Затем, работая в Европейском центре ядерных исследований в Женеве (CERN), он предложил коллегам публиковать гипертекстовые документы, связанные между собой гиперссылками. Бернерс-Ли продемонстрировал возможность гипертекстового доступа к внутренним поисковику и документам, а также новостным ресурсам Интернета. В результате, в мае 1991 года в CERN был утверждён стандарт WWW. Тим Бернерс-Ли является «отцом» основополагающих технологий веба – HTTP, URI/URL и HTML, хотя их теоретические основы были заложены ещё раньше. В 1940-х годах Ванневар Буш выдвинул идеи расширения памяти человека с помощью технических устройств, а также индексации накопленной человечеством информации для её быстрого поиска. Теодор Нельсон и Даг Энгельбарт предложили технологию гипертекста – «ветвящегося» текста, предоставляющего читателю разные варианты чтения. Xanadu, так и не законченная гипертекстовая система Нельсона, была предназначена для хранения и поиска текста, в который введены взаимосвязи и «окна». Нельсон мечтал связать перекрёстными ссылками все тексты, созданные человечеством. В настоящее время Тим Бернерс-Ли возглавляет основанный им Консорциум Всемирной паутины (World Wide Web Consortium), который занимается разработкой и внедрением стандартов Интернета. Наличие сайта – это серьезный шаг на пути поддержания репутации фирмы в целом, это эффективный инструмент PR. Благодаря эффективному, добротно сделанному современному сайту клиентам фирмы намного легче будет убедиться в ее конкурентоспособности и конкурентоспособности ее товаров, работ или услуг. Поэтому рассматриваемая тема является актуальной. Данная работа состоит из введения, главы, заключения и списка литературы.

Этапы жизненного цикла web – ресурса

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

1. Исследование предметной области, анализ.

2. Систематизация и построение спецификаций.

3. Разработка дизайна.

4. Написание «контента», текста для сайта.

5. «Кодирование», непосредственная разработка системы.

6. Тестирование.

7. Реклама и продвижение.

8. Обслуживание, обновление, внесение изменений.

Как только клиент начинает обсуждать требования, команда разработчиков осуществляет их предварительный анализ. Задаются следующие вопросы: как web-сайт станет частью системы, как web-сайт или приложение на основе web-технологий планируется внедрить в систему, присоединиться к существующей системе и как web-сайт сможет помочь данному бизнесу. Подобные вопросы задаются на стадии формирования требований к будущей системе. Одна из главных вещей, к определению которой должны прийти заказчик с разработчиков – это целевая аудитория, для которой будет предназначаться разработанная система. На входе мы имеем: интервью с потенциальными клиентами системы; дискуссии и обсуждения; онлайн чаты; записанные телефонные беседы; модели сайта, примеры. На выходе получаем: план работ; оценка стоимости; требования к команде разработчиков; требования к программному обеспечению и железу; поддерживающие документы; санкционированные разрешения, и т.д. Пример 1:

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

Пример 2:

Завод по переработке нефти решает выйти на региональный рынок и планирует заявить о себе, как серьезной компании через Интернет. Основная аудитория данного сайта – непосредственные клиенты завода, респектабельные бизнесмены с доходом выше среднего, практическим складом ума и всеми вытекающими из этого параметрами. Опираясь на эти доводы будет производиться разработка web-ресурса.

Пример 3:

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

Следующей стадией является стадия систематизации и построения спецификаций. Систематизация и построение спецификаций требуется для точного определения вида программного продукта, который будет получен на конечных стадиях жизненного цикла разработки web-сайта. От описания и от подробной спецификации будет зависеть то, будет ли уже реализованная система удовлетворять всем требованиям заказчика. Данным этапом очень часто пренебрегают, что может повлечь впоследствии за собой достаточно сильные разногласия между исполнителем и заказчиком в виде реализованного продукта, только точная спецификация и документация на продукт могут разрешить все возможные споры с обеих сторон, это очень важный пункт. Крупные проекты требуют глубоких исследований для удовлетворения технических и бизнес требований. На входе мы имеем: заключения от команды аналитиков. На выходе получаем: утвержденные требования и спецификации. Третьим этапом разработки web – ресурса является разработка дизайна. После утверждения всех планов ведутся работы по созданию дизайна будущей системы, в Интернете дизайн программной системы является очень важной составляющей всего программного продукта. На начальных этапах разработки дизайна строится прототип системы, на котором отображаются все модули будущей системы, их места расположения и пожелания по оформлению. Разрабатываются удобные интерфейсы системы, и после утверждения общей концепции дизайна эстафета передается дизайнерам. Дизайнер, на основе высказанных предложений и пожеланий к системе, а так же прототипов и разработанных интерфейсов системы создает графическое отображение страниц сайта. На входе мы имеем: документации, спецификации, пожелания. На выходе получаем: дизайн сайта, шаблон сайта, изображения и прототипы. Следующий этап – написание контента, текста для сайта. В отличие от программного обеспечения, наличие текста («контента») на страницах сайта является обязательным, и тому существует множество причин, вытекающих и из поисковой оптимизации и из дружественности интерфейса. Полноценному сайту недостаточно наличие 3-х полей ввода и 2-х кнопочек для реализации всей системы. Профессиональные разработчики контента для сайта (копирайтеры, рерайтеры) – люди, которые разрабатывают контент для страниц сайта с учетом всех специфик разрабатываемого сайта (тематика, аудитория, дизайн). На входе мы имеем: дизайн сайта, пожелания. На выходе получаем: сайт с форматированным готовым, уникальным и полезным контентом. Пятый этап – кодирование процессов, разработка сайта. Разработчики должны понимать получившийся дизайн и навигацию. Если система представляет динамичные данные, то разработчики должны использовать стандартизированные шаблоны для представления данных. На данной стадии разрабатывается весь программный код, реализуется логика работы приложения, реализуется весь описанный в спецификации функционал по стандартам, так же описанным в спецификациях. На входе мы имеем: сайт с формами и требованиями в спецификациях, сверстанный дизайн. На выходе получаем: спроектированную базу данных и сам web-сайт, документацию к разработанному продукту и наличие обязательных комментариев в коде. Шестой этап – тестирование. Тестирование – процесс выявления ошибок и их описания, смысл данной стадии полностью совпадает с тестирование любого программного обеспечения. Применяются как стандартные подходы к тестированию модульному, интеграционному, так и стресс тестирование и нагрузочное тестирование для выявления жизнеспособности системы при высоких нагрузках (большом числе посещений системы). На входе мы имеем: функционально готовый web-сайт и спецификации. На выходе получаем: отчеты о выявленных ошибках. Следующий этап – реклама и продвижение. Эта стадия применима только к web-сайтам. Поскольку веб-сайты – это системы, которые предоставляют свой функционал без предварительной установки на персональный компьютере и для доступа к web-сайту и его использованию чаще всего достаточно знания его адреса, то для того, чтобы узнать его адрес и вообще получить адрес требуемого нами web-сайта пользователи чаще всего обращаются к поисковым системам. Для продвижения сайта в поисковых системах в него вносятся специальные конструкции, которые облегчают поисковым системам идентификацию страниц сайта и выдачу их в результатах поиска. Применяемые технологии: метатеги, SEO оптимизация, продвижение по поисковикам, контекстная реклама. Продвижение сайта в поисковиках, SEO оптимизация так же имеет жизненный цикл и является отдельным процессом от разработки интернет-приложения, поскольку фактически прямым образом не имеет прямого влияния на функциональность и содержание сайта, а предоставляет лишь дополнительные сервисы по доступу к информации сайта через поисковые системы. На входе мы имеем: работающий интернет-сайт. На выходе получаем: сайт, быстро доступный через поисковые системы и другие каналы привлечения прямой аудитории. Восьмой этап и последний – это обслуживание, обновление, внесение изменений. Веб-сайт, как живой организм. Он всегда должен соответствовать настоящему времени и к нему в этом плане гораздо больше требований, чем к обычному программному обеспечению, Первоочередной задачей веб-сайта является предоставление актуальных на данный момент сервисов и услуг, информации. Поэтому эти виды данных требуют постоянного обновления и поддержания актуальности.

Заключение

Жизненный цикл – это период, в течение которого сайт существует, т.е. достигает максимальной точки своего развития и начинает «стареть». При этом есть сайты с минимальным жизненным циклом, существующие от нескольких дней до нескольких месяцев (дорвеи, сайты-сателлиты, сайты-пробники, сайты-тесты, домашние страницы ит.п.), и крупные проекты, для которых он охватывает годы. Жизненный цикл сайта включает все действия от момента появления идеи до конца срока его эксплуатации. Исследователи называют от трех до восьми этапов жизненного цикла сайта. В целом это такие этапы: разработка бизнес-плана (проектирование, рождение сайта), технического задания, изготовление Web-сайта, тестирование и запуск в эксплуатацию, продвижение (реклама, партнерство), поддержка и модернизация, закрытие сайта. Все сайты проходят через эти этапы. Разница между эффективным и неэффективным сайтом заключается в скорости и качестве их прохождения, в результате (достижении поставленных целей и задач) и в конечном итоге в изменении количества посетителей. Эффективность сайта необходимо закладывать еще на этапе проектирования сайта. Ее обеспечивают открытость ресурса для пользователя (возможность осуществления обратной связи); актуальность, корректность и уникальность предоставляемых услуг, информации; применение общедоступных (по возможности бесплатных для пользователя) технологий; логичность и продуманность ресурса; возможность оперативного изменения, добавления, перегруппировки информации; комфортность использования ресурса. Важно не пропустить момент, когда прибыль от сайта начинает снижаться. В это время необходима реконструкция сайта, после которой прибыль от сайта увеличивается. При этом достижение нового пика прибыли происходит в более короткие сроки. Далее всё повторяется снова, пока существует конкретный бизнес. Обычно процедура реконструкции включает в себя следующие этапы: реконструкция общей структуры сайта, его навигации и структуры разделов (описание “прозрачной” и контекстной навигации по сайту, структуры презентуемой информации); пересмотр принципов подачи информации на сайте (аудит. адаптация и коррекция материалов); пересмотр принципов оформления (редизайн; “оживление” контента наглядными иллюстрациями); реконструкция функционала сайта (технический аудит, анализ функциональных элементов, описание новых функциональных элементов). Редизайн сайта рекомендуют проводить не реже раза в год-полтора. Необходимость редизайна сайта может быть вызвана различными причинами: изменение среднего разрешения экрана монитора у посетителей сайта (частично эту проблему можно решить за счёт выбора грамотной компоновки сайта), устаревание информации (текст, фотографии и т.д.), размещённой на сайте. Таким образом, жизненный цикл сайта, а, следовательно, и изменение посещаемости сайта, зависит от ряда причин, основными среди которых являются следующие: раскрутка и продвижение сайта; количество людей, интересующихся данной тематикой; размер целевой аудитории; количество сайтов-конкурентов. Изучение жизненного цикла сайта позволит фирме не терять своих позиций на рынке.

Список использованной литературы

1. Кэмпбел М. Строим web – сайты / М. Кэмпбел – Москва: Издательство Триумф, 2006. – 480 с.

2. Лопак Л. Web – дизайн для чайников / Л. Лопак – 2-е издание. – Москва: ООО «И.Д. Вильямс», 2008. – 312 с.

3. Панфилов К. По ту сторону веб-страницы / К.Панфилов. – Москва: ДМК Пресс, 2008. – 440 с.

4. Серых Ю.А. Современный веб-дизайн / Ю.А. Серых. – Москва: ООО «И.Д. Вильямс», 2008. – 304 с.

5. Электронный ресурс / Режим доступа: https://www.antula.ru – Дата доступа: 09.11.2012 г.

6. Электронный ресурс / Режим доступа: https://www.codenet.ru – Дата доступа: 09.11.2012 г.

7. Электронный ресурс / Режим доступа: https://www.wikipedia.org – Дата доступа: 09.11.2012 г.

8. Электронный ресурс / Режим доступа: https://www.xbb.uz – Дата доступа: 09.11.2012 г.

Управление проектами и задачами

В качестве системы «Issue & project tracking» мы, в Mail.ru, используем Atlassian Jira, которая является стандартом де-факто среди крупных организаций. Вот далеко не полный список компаний, использующих Jira: ru.wikipedia.org/wiki/Atlassian_JIRA. По функционалу, гибкости, расширяемости и удобству использования этой системе нет равных, и альтернативы я не вижу, хотя по имеющейся у меня информации некоторые крупнейшие IT-компании с тысячами сотрудников успешно (по их заверениям) используют Bugzilla в качестве багтрекера.

Для небольших команд и проектов целесообразнее использовать менее навороченные и более бесплатные аналоги вроде той же Bugzilla, Phabricator или Redmine. Как вариант, в случае использования хостинга проектов (GitHub, BitBucket и другие) можно использовать встроенные в них системы отслеживания ошибок.

На данный момент проект «Календарь» в Jira содержит 1816 задач, из которых 1386 успешно закрыты. Около 500 из них были багами =)

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

Система контроля версий

На сегодняшний день самыми распростанёнными системами контроля версий являются Git и Mercurial. Обе имеют, по большому счёту, схожий функционал (распределённые системы), хоть и различаются в деталях. Практически все проекты Mail.ru перешли на Git (кто с SVN, кто вообще с CVS), и Календарь – не исключение.

В нашей компании есть несколько больших и мощных серверов, на которых установлен gitosis для хостинга git-репозиториев. Разные репозитории имеют разные настройки, например, у разработчиков не получится запушить в репозиторий календаря код Python, который не соответствует стандартам PEP8 (за этим следит специальный хук на сервере).

Весь код Календаря (frontend и backend) хранится в одном репозитории. Для небольшого и среднего проекта это позволяет быстро разворачивать весь проект целиком и легко отслеживать любые изменения в коде. Для больших и очень больших проектов (таких как Почта Mail.ru) более удобным представляется хранение клиентского и серверного кода в отдельных репозиториях (а то и нескольких), хотя, конечно, любой подход требует осмысленного и аргументированного решения.

На сегодняшний день у нас в репозитории Календаря 7175 коммитов, а за всё время было создано около 300 веток. Размер всего проекта 60 Мб.

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

Окружение для разработки

Говорят, что каждое правило в технике безопасности написано кровью. В IT-компаниях до такого, конечно, не доходит, но жёсткие правила, тем не менее, есть. Например, в Mail.ru только системные администраторы имеют доступ на «боевые» серверы и к данным реальных пользователей. Разработчикам доступны лишь тестовые машины с тестовыми пользователями, которая никак не связана с «живой», и вся разработка ведётся только в тестовой сети. Такое разделение обязанностей избавляет самых «умных» программистов от соблазна что-нибудь «быстренько поправить на живом» и заставляет более вдумчиво и качественно писать код.

Есть системы, которые очень трудно, а иногда и невозможно запустить на одной машине, например, Почта Mail.Ru: для полноценной работы ей требуется огромное количество библиотек, демонов, скриптов и сервисов. Такие проекты запускаются на нескольких (десятках) виртуальных серверов в тестовой сети, и разработчики работают с кодом, запущенным на этих машинах (vim, emacs, diff, вот это всё).

Нам в Календаре повезло: весь проект достаточно легко запускается на локальной машине разработчика и никаких проблем с разработкой нет. Для работы можно без ухищрений использовать любимые редакторы, IDE и отладчики, каждый программист работает со своим кодом и никак не влияет на работу других. Конечно, у нас тоже есть виртуальные серверы в девелоперской сети, но они используются, в основном, для тестирования. Ещё больше облегчает работу тот факт, что все в Календаре предпочитают использовать MacBook в своей работе, поэтому среда разработки практически не различается у членов команды.

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

pip install -r requirements/development.txt

из склонированного репозитория. Клиентская (фронтенд) часть использует npm и все зависимости ставятся так же легко и непринуждённо.

Сейчас в календаре используется 33 сторонние библиотеки Python.

Всё необходимое ПО на маке ставится из brew, и для первоначальной установки проекта на компьютер разработчика достаточно запустить

brew install …

со списком зависимостей. Конечно, одной команды недостаточно и потребуется дальнейшая настройка, например, инициализация пользователя и БД в PostgreSQL. В установке отдельных программ есть некоторые особенности (например, мы используем патченный nginx со своими модулями), но это не вызывает никаких проблем, потому что всё описано в системе документации (wiki).

Документация по проекту

Знание – сила. Знаниями стоит делиться со своими коллегами, их нужно записывать, чтобы не забыть самому. Идеальным местом для хранения информации являются wiki-системы, и в Mail.ru мы испольуем Atlassian Confluence в качестве таковой. Особых преимуществ перед другими wiki-системами у Confluence я не вижу (их функционал, по сути, схож), но так сложилось, что продукция Atlassian прижилась в нашей компании и пользуется популярностью. Хотя одно достоинство всё-таки есть: продукты одной компании легко интегрировать друг с другом, а в любой крупной компании все внутренние сервисы так или иначе связаны друг с другом.

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

В проекте Календарь в Confluence 122 страницы документации.

Любому продукту нужен контроль качества и наш Календарь не исключение.

Code review

Каждый разработчик сталкивается с ошибками в коде. Первый шаг в борьбе за качество – code review, это позволяет своевременно заметить любые огрехи в программе. Ещё одно достоинство аудита кода заключается в знакомстве с каждым коммитом как минимум двух программистов: того, кто написал код и того, кто его ревьюил (соответственно, ответственность так же делится пополам).

У Atlassian для code review есть шикарный инструмент Сrucible, но так исторически сложилось, что мы в Календаре используем Phabricator: open-source разработку от Facebook. У фабрикатора много возможностей, но мы используем лишь часть из них, а именно аудит, комментирование кода и просмотр репозитория онлайн.

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

После исправления замечаний коллег код проходит на следующие этапы контроля качества.

Синтаксический контроль и тестирование

Красивый код – хороший код. Следование правилам code-style всеми членами команды позволяет с первого взгляда разобраться в любом месте программы, а так же позволяет избежать подавляющего большинства глупых ошибок. Каждый пуш в репозиторий календаря проверяется с помощью PEP8, pyflake и pylint.

В календаре нет ни одного исключения из правил pep8 и pyflake.

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

На сегодняшний день у нас в проекте 580 автоматических тестов.

Для запуска различных задач мы используем open-source систему Jenkins CI (Continuous integration), в которой имеется три задания для календаря:

для тестовых веток: синтаксический контроль (lint) кода, запуск всех тестов, подготовка отчёта code coverage
для ветки prerelease: синтаксический контроль (lint) кода, запуск всех тестов, сборка тестового пакета (RPM) проекта и раскладка его на наш пререлизный (тестовый) сервер
для ветки master: запуск тестов и сборка пакета (RPM) проекта

Все задачи запускаются при пуше соответствующей ветки по хуку в git-репозитории.

Сборка проекта длится, в среднем, около пяти минут.

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

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

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

Раскладка проекта в бой

Админы – люди умные и ленивые. Если часто приходится делать рутинные операции, то почему бы их не автоматизировать?

В Mail.ru многие тысячи серверов, у каждого своя роль и свои настройки. Для управления конфигурациями серверов мы используем Puppet. Настройки каждой группы серверов описываются в простых файлах, которые лежат в системе контроля версий. Таким образом, всегда есть история изменений файлов конфигурации с возможностью откатиться в любое из предыдущих состояний. Доступ к репозиториям и к паппету в целом есть только у системных администраторов.

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

Раскладка проекта занимает около одной минуты.

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

Логгирование ошибок

В первую очередь нас интересуют, так называемые, «пятисотки», то есть критические ошибки на сервере. Если они есть (а они бывают, от этого никуда не деться), значит что-то пошло не так и нужно в срочном порядке готовить багфиксы. Как поймать такие ошибки? Можно, конечно, писать всё в лог, и тогда простым «грепом» (поиском по файлу лога) мы всегда будем в курсе о количестве и типе ошибок, но есть вариант получше.

Система логгирования в Календаре настроена таким образом, чтобы отправлять все ошибки, исключения и просто варнинги в специальну систему под названием Sentry. В ней мы видим не только статистику по ошибкам (когда, какие ошибки и сколько раз возникали), но и подробнейшую информацию об этих ошибках: полный traceback (порядок вызова функций) со значением всех переменных в контексте каждой функции. Так же имеется информация о пользователе (, ОС, браузер) и запросе (url, заголовки, GET и POST параметры). Все браузерные ошибки так же попадают в Sentry, правда, информация не столь подробна (JavaScript, ничего не поделаешь). Всё это позволяет легко локализовать проблемы и в кратчайшие сроки исправлять ошибки.

В основном, мы пишем в Sentry различные предупреждения. Например, в процессе рефакторинга, прежде чем отказаться от какой-нибудь функции мы всегда добавляем warning в неё, и только при отсутствии сообщений в Sentry, в следующую итерацию, эта функция будет окончательно удалена из кода. Бывают, конечно, и ошибки, бывает и много ошибок («факапы»).

В Sentry Календаря попадает, в среднем, около 100 сообщений в час. Sentry выдерживает тысячи ошибок в минуту (проверено на практике =).

Логгирование – хорошо, но этого недостаточно, проекту жизненно необходима статистика.

Статистика и графики

Статистику любят все. Менеджеры любуются ею, радуясь увеличению количества хитов и пользователей, разработчики получают информацию о «здоровье» проекта. Мы используем Graphite в качестве системы для сбора и хранения метрик, а так же sD – сервер, который обрабатывает и аггрегирует входящие метрики, передавая их на хранение во всё тот же графит.

Для чего нужны графики? Как я уже говорил, по графикам всегда можно судить о состоянии проекта: внезапно увеличилось количество редиректов, выросло в два раза среднее время запроса в базу или увеличилось количество операций ввода-вывода на одном из серверов. Всё это позволяет обнаружить проблему, а наличие истории (графики хранятся месяцами и годами) облегчают анализ внезапных неприятностей с проектом.

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

Графики показателей сервера (мы используем Diamond для этого) позволяют своевременно оценить нагрузку и заблаговременно заказать дополнительные машины или же озаботиться производительностью программ.

В графит Календаря каждую минуту пишется около 25 тысяч различных метрик.

Любой проект пишется не для логов и не для графиков: он пишется для людей, для наших любимых пользователей. И пользователи иногда бывают недовольны проектом.

Общение с пользователями

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

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

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

Вместо послесловия

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

Хочется попробовать использовать Vagrant при разработке, это позволит ещё быстрее и проще разворачивать девелоперское окружение. Очень хочется попробовать Selenium для автоматического тестирования проекта (веб-версии и мобильных клиентов). Для более качественного тестирования нового функционала не хватает возможности включать оный по критериям, например, только на сотрудников компании или на определённый процент пользователей, хотим попробовать open-source проект Gargoyle для этого. В ближайшее время, по примеру других Python-проектов в нашей компании, наша команда собирается внедрить Arcanist: надстройку над git для работы с Phabricator из командной строки в репозитории проекта. Это позволит ещё больше упростить процесс code-review и облегчить разработку.

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

Владимир Рудных,

Технический руководитель Календаря Mail.Ru.

Источник