keepsimple
dark
en | ru

#9. Технические детали проекта

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

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

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

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

Ууу как все серьезно. Я заговорил метафорами ☺))))

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

Сервер

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

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

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

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

Хостинг

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

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

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

  • Размер оперативной памяти;
  • Тип процессора и кол-во ядер;
  • Тип жесткого диска (HDD / SSD) и его объем;
  • Объем сетевого трафика;

И множество других.

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

Промежуточные серверы (Staging Servers)

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

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

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

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

Спойлер:

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

Каждый прямоугольник – это сервер.

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

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

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

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

Вот и все.

К сожалению, подобного подхода придерживаются только наиболее дисциплинированные и серъезные компании, тогда как большинство ограничиваются 2-3 серверами максимум (Dev -> Staging (для QA и Клиента) -> Prod).

Базы Данных

Неотъемлемый компонент любого проекта. В сухом остатке, База Данных это некая виртуальная (обычно) таблица с данными. К примеру, когда вы заходите на 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. Сервис имеет бесплатную составляющую, поэтому его используют совершенно все, кому не лень(Мне не лень, Большой Брат следит за тобой). Вообще, отдельно поизучать Google Analytics было бы полезно всем, кто работает в IT, как минимум для того, чтобы представить возможности этого внушительного инструмента.

Итог

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

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

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

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