#9. Технические составлящие проекта разработки ПО

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

Цель этой статьи проста. Я хочу чтобы вы в общих чертах ознакомились с наиболее популярными техническими компонентами используемыми во всех проектах.

На вопрос «А зачем менеджеру знать техническую часть, если его работа практически никак к ней не относится?» отвечу: «Потому, что невозможно достичь высокого качества в управлении IT-проектами, если ты не знаешь какими понятиями и инструментами твои команды оперируют, и как твои проекты технически устроены».

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

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

Сервером называется некая программа, ключевая функция которой в обработке запросов клиентов.

Например, вы используете браузер чтобы открыть эту страницу. В данном случае ваш браузер – это клиент, а программа, находящаяся по адресу https://keepsimple.io/ru, которая обрабатывает ваш запрос и открывает эту страницу – Веб-Сервер.

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

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

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

Хостингом называется сервис предоставления некоего пространства в Интернете для нашего сервера.

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

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

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

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

Дело в том, что для грамотной разработки проекта одного сервера не достаточно. Тот сервер, который в конечном итоге будет открыт для широкой публики в день запуска проекта (релиза) – называется Production server-ом. На него обычно устанавливаются готовые инкременты, которые не только завершены с точки зрения разработки, но и одобрены клиентом. Но ведь перед одобрением мы должны провести Демо, а перед Демо тестировщики должны провести свои тесты...

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

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

Каждый прямоугольник = один сервер:

 

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

Красный – это сервер среды разработки (Dev. Server, или просто Dev). На этом сервере разработчики постоянно что-то меняют, и здесь вполне может что-то не работать.

Бледно-желтый – QA сервер для тестирования. По сути, на Dev-е, где постоянная рутина, разрабатываются инкременты которые попали в Спринт. А сюда попадают те инкременты, которые были помечены разработчиками как «завершенные» и «готовые к тестированию» (мы же помним колонки «In Progress» и «Testing» на нашей Канбан доске?). Таким образом, тестировщики могут проводить свои тесты на своих серверах, зная, что эти серверы изолированы от того хаоса и нестабильности, который может происходить на Dev. Сервере.

Золотой – UAT среда. UAT переводится как User Acceptance Testing (Пользовательское Тестирование). Обычно, после того, как разработчики получают «добро» от тестировщиков, программа, в том ее виде, в котором она находится на QA-сервере, попадает на UAT, где Клиент может сам увидеть результаты работы команды и дать им оценку. Демо, обычно, проводится на UAT сервере.

Салатовый – UAT-2. Основное отличие от UAT в том, что если UAT, QA и Dev серверы могут иметь низкие технические характеристики (нет смысла арендовать дороженный сервер способный выдержать нагрузку десятков миллионов пользователей, когда твоя команда, которая занимается разработкой состоит из пары десятков человек), то UAT-2 это сервер, который по техническим параметрам полностью повторяет Production сервер. Делается это для того, чтобы провести на UAT-2 те тестирования, которые невозможно провести на предыдущих серверах (например, тот же stress-test нагрузки).

Кол-во серверов, и их предназначение определяется размером и критичностью проекта. Проект Keepsimple, например, имеет два сервера: Staging сервер, где мы вносим изменения и валидируем новые фичи, и Production сервер, с которого вы прямо сейчас читаете этот текст.

Неотъемлемый компонент любого проекта. В сухом остатке, База Данных это некая виртуальная таблица (обычно) с данными. К примеру, когда вы заходите на facebook.com и вводите свой логин и пароль, система сверяет правильность введенных вами данных с данными указанными в таблице одной из таблиц базы данных Facebook. Либо, когда вы регистрируетесь на каком-то сайте, те данные, которые вы ввели во время регистрации создают новые записи в базе данных этого вебсайта, чтобы впоследствии вас можно было верифицировать и так далее.

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

К примеру, если наш проект имеет потенциальный рынок в 50 миллионов пользователей, и мы ожидаем, что в первую неделю нас посетит не менее 10 миллионов, мы можем провести стресс-тест сервера, с симуляцией нагрузки, используя специализированные онлайн сервисы (locust, loader.io etc), чтобы быть уверены, что мощности наших серверов хватит, чтобы справиться с этой нагрузкой. Если тест провален, мы просто идем к нашему Хостеру, покупаем дополнительные мощности, и проводим тесты заново.

Если мы хотим проанализировать, насколько эффективно открываются страницы нашего сайта на стороне пользователей, мы можем настроить дополнительные системы анализа продуктивности (sitespeed.io, pagespeed insights, monitis, new relic, zabbix, etc). Если по результатам анализа мы выявили, что некоторые компоненты нашей системы работают слишком медленно, тогда это может стать сигналом для разработчиков, чтобы открыть коды этих компонентов и найти пути для их оптимизации.

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

Если же мы хотим проводить специальный мониторинг какой-то специфической активности, нужной нам для каких-то конкретных целей, то для этого тоже есть целый ряд инструментов (graylog, kibana, logstash etc).

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

Мы бы хотели знать какие слова вводятся нашими пользователями в Google, прежде чем они попадут на наш сайт, и безусловно, не лишним было бы заодно знать какими устройствами они пользуются (smartphones, tablets, pc) и какими платформами (windows, linux, mac).

К счастью для нас, бОльшая часть этой информации легко получается если мы настроим Google Analytics. Сервис имеет бесплатную версию, поэтому его используют совершенно все, кому не лень (Мне не лень, Большой Брат следит за тобой. Keepsimple активно использует GA). Вообще, отдельно поизучать Google Analytics было бы полезно всем, кто работает в IT, как минимум для того, чтобы представить возможности этого внушительного инструмента.

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

На самом деле, я очень хотел написать про GIT, SVN, Непрерывную Интеграцию, Непрерывную Доставку и Непрерывное Развертывание (Continuous Integration (CI), Continuous Delivery (CD), Continuous Deployment), попутно указав разницу, и смысл каждой из этих практик, но мне кажется, что от этого статья станет слишком технической и сложной для освоения.

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

Теперь, когда мы обладаем знаниями о том, что такое проект и как он составляется, да еще и знаем где он и как собирается технически, мы готовы взглянуть на кооперацию между Компанией-Клиентом и Компанией-Разработчиком, «свысока».