index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Инфраструктура ИТ on Инфраструктура ИТ</title>
    <link>https://vitalyzhakov.github.io/</link>
    <description>Recent content in Инфраструктура ИТ on Инфраструктура ИТ</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>ru-ru</language>
    <copyright>&amp;copy; 2018</copyright>
    <lastBuildDate>Wed, 20 Apr 2016 00:00:00 +0000</lastBuildDate>
    <atom:link href="/" rel="self" type="application/rss+xml" />
    
    <item>
      <title>Генерация паспорта устройства</title>
      <link>https://vitalyzhakov.github.io/post/device-passport/</link>
      <pubDate>Mon, 13 Jun 2022 00:10:06 +0500</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/device-passport/</guid>
      <description>

&lt;p&gt;Часто в комплекте с устройствами поставляются их паспорта, которые содержат техническую спецификацию.
На производстве выпускается несколько модификаций одного и того же устройства.
Как сейчас - паспорта создаются путём копирования похожего и внесения в него изменений, что приводит к человеческим ошибкам.&lt;/p&gt;

&lt;h2 id=&#34;требования&#34;&gt;Требования&lt;/h2&gt;

&lt;p&gt;Основные параметры шаблона зависят от маркировки.
Маркировка - это строка вида DSA XXXX DS XX XX XX, где каждый символ - выбор характеристики из словаря.&lt;/p&gt;

&lt;p&gt;Кроме маркировки нужно указать точные характеристики, не вынесенные в маркировку (в том числе серийный номер).&lt;/p&gt;

&lt;h3 id=&#34;пользователи&#34;&gt;Пользователи&lt;/h3&gt;

&lt;p&gt;Поддержка двух групп пользователей:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;оператор - доступ для генерации паспорта;&lt;/li&gt;
&lt;li&gt;редактор - внесение изменений в шаблон паспорта или список параметров.&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&#34;c4-диаграммы&#34;&gt;C4 диаграммы&lt;/h2&gt;

&lt;h2 id=&#34;решение&#34;&gt;Решение&lt;/h2&gt;

&lt;p&gt;Для каждого типа оборудования создать xml-спецификацию&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-xml&#34;&gt;&amp;lt;?xml

&amp;lt;head&amp;gt;
    &amp;lt;title&amp;gt;
        Спецификация для паспорта DSA
    &amp;lt;/title&amp;gt;
&amp;lt;/head&amp;gt;

&amp;lt;template path=&amp;quot;templates/dsa.latex&amp;quot;&amp;gt;
&amp;lt;/template&amp;gt;

&amp;lt;form&amp;gt;
    &amp;lt;mark&amp;gt;
        &amp;lt;static&amp;gt;DSA-&amp;lt;static&amp;gt;
        &amp;lt;select name=&amp;quot;1&amp;quot;&amp;gt;
            &amp;lt;label&amp;gt;Количество входов&amp;lt;/label&amp;gt;
            &amp;lt;option value=&amp;quot;1&amp;quot;&amp;gt;1&amp;lt;/option&amp;gt;
            &amp;lt;option value=&amp;quot;2&amp;quot;&amp;gt;2&amp;lt;/option&amp;gt;
        &amp;lt;/select&amp;gt;
        &amp;lt;select name=&amp;quot;2&amp;quot;&amp;gt;
            &amp;lt;label&amp;gt;Измеряемая величина&amp;lt;/label&amp;gt;
            &amp;lt;option value=&amp;quot;1&amp;quot;&amp;gt;Измерение зазора в плоскости&amp;lt;/option&amp;gt;
            &amp;lt;option value=&amp;quot;2&amp;quot;&amp;gt;Максимальное значение в области зазора&amp;lt;/option&amp;gt;
        &amp;lt;/select&amp;gt;
        &amp;lt;select name=&amp;quot;3&amp;quot;&amp;gt;
            &amp;lt;label&amp;gt;Температурный диапазон&amp;lt;/name&amp;gt;
            &amp;lt;option value=&amp;quot;1&amp;quot;&amp;gt;4-10 С&amp;lt;/option&amp;gt;
            &amp;lt;option value=&amp;quot;2&amp;quot;&amp;gt;-20 +50 С&amp;lt;/option&amp;gt;
        &amp;lt;/select&amp;gt;
    &amp;lt;/mark&amp;gt;

    &amp;lt;modification&amp;gt;
        &amp;lt;select name=&amp;quot;4&amp;quot;&amp;gt;
            &amp;lt;label&amp;gt;Диапазон измерений&amp;lt;/label&amp;gt;
            &amp;lt;option value=&amp;quot;5-20 mA&amp;quot;&amp;gt;5-20 mA&amp;lt;/option&amp;gt;
            &amp;lt;option value=&amp;quot;1-18 mA&amp;quot;&amp;gt;1-18 mA&amp;lt;/option&amp;gt;
        &amp;lt;/select&amp;gt;
        &amp;lt;select name=&amp;quot;7&amp;quot;&amp;gt;
            &amp;lt;label&amp;gt;Температурный диапазон&amp;lt;/label&amp;gt;
            &amp;lt;option value=&amp;quot;1&amp;quot;&amp;gt;4-10 С&amp;lt;/option&amp;gt;
            &amp;lt;option value=&amp;quot;2&amp;quot;&amp;gt;-20 +50 С&amp;lt;/option&amp;gt;
        &amp;lt;/select&amp;gt;
    &amp;lt;/modification&amp;gt;


    &amp;lt;label form=&amp;quot;8&amp;quot;&amp;gt;Серийный номер&amp;lt;/label&amp;gt;
    &amp;lt;input name=&amp;quot;8&amp;quot;&amp;gt;&amp;lt;/input&amp;gt;
&amp;lt;/form&amp;gt;

?&amp;gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Здесь id - наименование параметра, передаваемого в шаблон.&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Масштабирование от нуля до миллиона пользователей</title>
      <link>https://vitalyzhakov.github.io/post/scaling-from-zero-to-millions-of-users/</link>
      <pubDate>Wed, 10 Nov 2021 00:10:06 +0500</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/scaling-from-zero-to-millions-of-users/</guid>
      <description>

&lt;h2 id=&#34;настройка-одного-сервера&#34;&gt;Настройка одного сервера&lt;/h2&gt;

&lt;p&gt;Путь в тысячу миль начинается с первого шага и в проектировании сложных систем аналогично.
Чтобы начать с чего-то простого, всегда запускаются на одном сервере.&lt;/p&gt;

&lt;p&gt;Рисунок 1-1 демонстрирует одиночный сервер, в котором всё запущено на 1 сервере: веб приложение, база данных, кеш и т.д.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-1.png&#34; alt=&#34;Рисунок 1-1&#34; title=&#34;Рисунок 1-1&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Для того, чтобы понять конфигурацию, полезно исследовать поток запроса и источники траффика.
Давайте для начала посмотрим на движение запроса.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-2.png&#34; alt=&#34;Рисунок 1-2&#34; title=&#34;Рисунок 1-2&#34; /&gt;&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Пользователи получают доступ к вебсайтам через доменные имена, такие как api.mysite.com.
Обычно Системы доменных имён (DNS) - это платный сервис, предоставляемый сторонними организациями и не обслуживаемый нашими серверами.&lt;/li&gt;
&lt;li&gt;Адрес интернет протокола (IP) возвращается в браузер или мобильное приложение. В примере возвращается адрес 15.125.23.214.&lt;/li&gt;
&lt;li&gt;Как только IP адрес получен, запрос Hypertext Transfer Protocol (HTTP) отправляется напрямую к вашему веб-серверу.&lt;/li&gt;
&lt;li&gt;Веб-сервер возвращает HTML-страницу или JSON-ответ. В общем случае может вернуть в теле ответа также изображения, видео и другие типы содержимого.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Далее, давайте проверим источники траффика. Траффик к нашему вебсерверу приходит из двух источников:
web и мобильное приложения.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Web приложение: использует комбинацию серверных языков (Java, Python, etc.) для обработки
бизнес-логики, хранения и т.д. и клиентских языков (HTML и JavaScript) для представления.&lt;/li&gt;
&lt;li&gt;Мобильное приложение: протокол HTTP - протокол коммуникаций между мобильным приложением и веб-сервером.
JavaScript Object Notation (JSON) - общеиспользуемый формат для передачи данных из-за его простоты.
Пример API ответа в формате JSON представлен ниже:&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;GET /users/12 – Retrieve user object for id = 12
&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/json-response-example.png&#34; alt=&#34;JSON response example&#34; title=&#34;JSON response example&#34; /&gt;&lt;/p&gt;

&lt;h2 id=&#34;база-данных&#34;&gt;База данных&lt;/h2&gt;

&lt;p&gt;С ростом базы данных один сервер может оказаться недостаточным, нам понадобится несколько серверов:
один для обработки web/mobile запросов, другой для базы данных (Рисунок 1-3).
Разделение web/mobile траффика (уровень web) и базы данных (уровень данных) позволяет масштабировать их независимо.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-3.png&#34; alt=&#34;Рисунок 1-3&#34; title=&#34;Рисунок 1-3&#34; /&gt;&lt;/p&gt;

&lt;h2 id=&#34;какую-базу-данных-использовать&#34;&gt;Какую базу данных использовать?&lt;/h2&gt;

&lt;p&gt;Вы можете выбирать между традиционной реляционной базой и нереляционной базой. Давайте поймём, в чём разница.
Реляционная база данных также называется реляционной системой управления баз данных (RDBMS) или SQL базой данных.
Самые известные представители - PostgreSQL, MySQL, Oracle database, и другие.&lt;/p&gt;

&lt;p&gt;Реляционная база данных представляет и хранит данные в таблицах и строках. Вы можете выполнять операции объединения используя язык запросов SQL
над разными таблицами базы данных.&lt;/p&gt;

&lt;p&gt;Нереляционные базы данных также называют NoSQL базами данных.&lt;/p&gt;

&lt;p&gt;Известные представители - CouchDB, Neo4j, Cassandra, HBase, Amazon DynamoDB, MongoDB, etc&lt;/p&gt;

&lt;p&gt;Эти базы данных группируются в 4 категории:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;хранилища ключ-значение;&lt;/li&gt;
&lt;li&gt;графовые хранилища;&lt;/li&gt;
&lt;li&gt;колоночные хранилища;&lt;/li&gt;
&lt;li&gt;документные хранилища.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Операции объединения обычно не поддерживаются в нереляционных базах данных.&lt;/p&gt;

&lt;p&gt;Для большинства разработчиков реляционная база данных - лучший выбор, потому что они существуют уже более 40 лет и исторически хорошо зарекомендовали себя.&lt;/p&gt;

&lt;p&gt;Однако если реляционные базы данных
не подходят для ваших конкретных случаев использования, важно исследовать, выходя за рамки реляционных
базы данных. Нереляционные базы данных могут быть правильным выбором, если:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;вашему приложению нужны очень низкие задержки;&lt;/li&gt;
&lt;li&gt;ваши данные не структурированные или у вас нет реляционных данных;&lt;/li&gt;
&lt;li&gt;вам достаточно сериализовывать и десериализовывать данные (JSON, XML, YAML и др.);&lt;/li&gt;
&lt;li&gt;вам нужно сохранять большие объёмы данных.&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&#34;вертикальное-и-горизонтальное-масштабирование&#34;&gt;Вертикальное и горизонтальное масштабирование&lt;/h2&gt;

&lt;p&gt;Вертикальное масштабирование, именуемое также &amp;ldquo;масштабирование вверх&amp;rdquo; означает процесс добавления мощности (ядра, память) на ваши сервера.
Горизонтальное масштабирование, именуемое также &amp;ldquo;масштабирование в ширину&amp;rdquo; позволяет масштабироваться путём добавления большего количества серверов в пул ресурсов.
Когда траффик небольшой, вертикальное масштабирование  - отличный вариант и простота вертикального масштабирования - это его главное преимущество.
К сожалению, оно имеет серьёзные ограничения:
* вертикальное масштабирование имеет жёсткий лимит. Невозможно бесконечно добавлять CPU и память к одному серверу;
* Вертикальное масштабирование не имеет аварийного переключения и резервирования. Если один сервер упал, вебсайт / приложение упадёт целиком.&lt;/p&gt;

&lt;p&gt;Горизонтальное масштабирование более желаемо для больших систем из-за ограничений вертикального.
В предыдущей варианте пользователи соединялись с веб-сервером напрямую. Пользователи не смогут достучаться до вебсайта, если вебсервер будет оффлайн.&lt;/p&gt;

&lt;p&gt;В другом сценарии, если много пользователей придут на вебсервер одновременно и достигнут лимита нагрузки, пользователи обычно получают ответ медленнее или не получают его совсем. Балансировщик нагрузки - лучшее решение для этой проблемы.&lt;/p&gt;

&lt;h2 id=&#34;балансировщик-нагрузки&#34;&gt;Балансировщик нагрузки&lt;/h2&gt;

&lt;p&gt;Балансировщик нагрузки распределяет входящий трафик по веб серверам, которые определены в балансируемом множестве.
Рисунок 1-4 показывает, как работает балансировщик нагрузки.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-4.png&#34; alt=&#34;Рисунок 1-4&#34; title=&#34;Рисунок 1-4&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Как показано на рисунке 1-4, пользователи соединяются с публичным IP балансировщика нагрузки напрямую.
В этой конфигурации веб сервера больше недоступны напрямую с клиентов.
В целях безопасности для коммуникации между серверами используются приватные IP.
Приватный IP - IP адрес, доступный только между серверами одной сети; таким образом, они недоступны через интернет.
Балансировщик общается с веб сервером через приватные IP.&lt;/p&gt;

&lt;p&gt;На рисунке 1-4, после того как мы добавили балансировщик и второй веб сервер, мы успешно решили вопрос аварийного переключения и улучшили доступность web зоны:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Если сервер 1 падает, весь траффик будет переадресован на сервере 2. Это снижает вероятность недоступности вебсайта. Мы также добавим второй сервер в пул
для балансировки нагрузки&lt;/li&gt;
&lt;li&gt;если траффик вебсайта быстро расчёт, 2 сервер может быть недостаточно, чтобы обработать весь траффик, балансировщик нагрузки может помочь решить эту проблему изящно. Вам достаточно добавить больше серверов в пул и балансировщик начнёт отправлять запросы к ним.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Сейчас web зона выглядит хорошо, что насчёт зоны данных? Текущий дизайн имеет одну базу, поэтому он не поддерживает аварийное переключение и избыточность.
Репликация баз данных - общепринятая техника для решения этой проблемы. Давайте посмотрим, как она работает.&lt;/p&gt;

&lt;h2 id=&#34;репликация-баз-данных&#34;&gt;Репликация баз данных&lt;/h2&gt;

&lt;p&gt;Цитата из википедии: &amp;ldquo;репликация баз данных может быть использована в системах управления базами данных, обычно с отношением
primary/replica между источником (primary) и копиями (replica).&lt;/p&gt;

&lt;p&gt;Primary база данных обычно поддерживает только операции записи. Replica берёт копию данных с primary и обслуживает запросы на чтение.
Все операции изменения данных, такие как insert, delete или update должны быть отправлены в primary базу.
Большинству приложений требуется намного больше операций чтения, чем записи.
Поэтому количество реплик в системе обычно больше, чем количество primary баз данных.
Рисунок 1-5 показывает primary базу данных с несколькими репликами.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-5.png&#34; alt=&#34;Рисунок 1-5&#34; title=&#34;Рисунок 1-5&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Преимущества репликации баз данных:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;Улучшение производительности: при использовании модели master-slave все операции записи и обновления происходят в master-узлах,
тогда как операции чтения распределены между репликами. Такая модель увеличивает производительность, поскольку
позволяет обрабатывать больше запросов одновременно.&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Надёжность: Если какой-либо из серверов баз данных выходит из строя из-за катастрофы (например, пожара или землетрясения),
данные остаются доступными. Можно не волноваться о сохранности данных, поскольку они реплицированы в несколько мест.&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Высокая доступность: При репликации данных, веб-сайт остаётся работающим, даже если база оффлайн, поскольку
есть возможность получить доступ к данным на другом сервере баз данных.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;В предыдущем разделе обсуждался вопрос, как балансировщик нагрузки помогает увеличить доступность системы.
Зададимся похожим вопросом и здесь: Что, если одна из баз данных отключится?
Архитектура, представленная на рисунке 1-5, может дать ответ:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;Если имеется только одна база-реплика, и она отключилась, операции чтения будут временно перенаправляться в master-базу.
Как только проблема будет найдена, новая реплика заменит неработающую. Если же имеется несколько баз-реплик,
запросы чтения будут перенаправлены на работающую копию, пока новая реплика не заменит неработающую.&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Если вышел из строя master-сервер, одна из реплик будет повышена до нового master-сервера.
Все операции будут временно выполняться на этой базе, и сразу будет создана новая реплика взамен повышенной.
В боевой среде задача повышения базы до master-сервера осложняется тем, что в репликах могут быть устаревшие данные.
Потерянную информацию можно восстановить запуском скриптов восстановления данных. Также могут помочь такие методы репликации,
как мульти-master и круговая репликация, но они более сложные и останутся за границами этого обзора.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Рисунок 1-6 показывает дизайн системы после добавления в неё балансировщика нагрузки и репликации баз данных.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-6.png&#34; alt=&#34;Рисунок 1-6&#34; title=&#34;Рисунок 1-6&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Давайте взглянем на дизайн&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;пользователь получает IP адрес балансировщика нагрузки из DNS;&lt;/li&gt;
&lt;li&gt;пользователь соединяется с балансировщиком нагрузки через этот IP адрес;&lt;/li&gt;
&lt;li&gt;Http запрос направляется на сервер 1 или сервер 2;&lt;/li&gt;
&lt;li&gt;веб сервер читает данные из базы slave;&lt;/li&gt;
&lt;li&gt;веб-сервер направляет операции изменения данных на базу master. Это включает в себя операции insert, update и delete;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Сейчас у вас есть уверенное понимание зон веб и данных. Настало время улучшить время загрузки / ответов.
Это может быть сделано добавлением кеширующего слоя или доставкой статического контента (JavaScript/CSS/картинки/видел файлы)
в сеть доставки контента (CDN).&lt;/p&gt;

&lt;h2 id=&#34;кеш&#34;&gt;Кеш&lt;/h2&gt;

&lt;p&gt;Кеш - временное хранилище результатов дорогих операций или часто запрашиваемых операций, таким образом что последовательные вызовы обслуживаются быстрее.
Как показано на рисунке 1-6, каждый раз, когда загружается новая веб страница, один или больше вызовов баз данных исполняется для получения данных.&lt;/p&gt;

&lt;p&gt;На производительность приложения сильно влияет многократный вызов базы данных.
Кеш может смягчить эту проблему.&lt;/p&gt;

&lt;h2 id=&#34;зона-кеширования&#34;&gt;Зона кеширования&lt;/h2&gt;

&lt;p&gt;Зона кеширования - временный слой хранения данных, более быстрый, чем база данных.
Преимущества зоны кеширования включают лучшую производительность системы, возможность снизить нагрузку на базу данных,
возможность масштабировать кеш зону независимо. Рисунок 1-7 показывает возможную конфигурацию сервера кеширования:&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-7.png&#34; alt=&#34;Рисунок 1-7&#34; title=&#34;Рисунок 1-7&#34; /&gt;&lt;/p&gt;

&lt;p&gt;После получения запроса веб сервер сначала проверяет, доступен ли в кеше ответ. Если да, отправляет ответ клиенту.
Если нет, отправляет запрос в базу данных, сохраняет ответ в кеше и отправляет клиенту.
Эта стратегия кеширования называется &amp;ldquo;сквозной кеш&amp;rdquo;.
Другие стратегии кеширования зависят от типов данных, размера и моделей доступа.&lt;/p&gt;

&lt;p&gt;Взаимодействие с серверами кеширования довольно простое, так как большинство кеширующих серверов предоставляет API для распространённых языков программирования.
Следующий кусок кода показывает типичное API Memcached:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;SECONDS = 1
cache.set (&#39;myKey&#39;, &#39;myValue&#39;, 3600*SECONDS)
cache.get (&#39;myKey&#39;)

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Рекомендации по использованию кеша&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;решите, когда использовать кеш. Общая рекомендация - использовать кеш, когда данные часто читаются, но меняются редко.
Поскольку кэшированные данные хранятся в энергозависимой памяти, кеш сервер - не идеальное место для хранения данных.
Например, при перезапуске кеш-сервера все данные в памяти будут потеряны.
Таким образом, важные данные должны быть сохранены в постоянном хранилище.&lt;/li&gt;
&lt;li&gt;политика устаревания. Хорошая практика реализовать политику устаревания. Когда кешированные данные устаревают, они удаляются из кеша.
Когда нет политики устаревания, данные будут храниться в кеше постоянно.
Желательно не делать срок истечения слишком коротким, это может привести к частым обращениям к базе данных.
Между тем, желательно не увеличивать срок жизни слишком надолго, это может привести к тому, что данные устареют.&lt;/li&gt;
&lt;li&gt;Согласованность: это включает поддержание хранилища данных и кеша в синхронном состоянии.
Несогласованность может случаться из-за того, что операции по изменению данных в хранилище и кеше не находятся в одной транзакции.
Когда речь идёт о масштабировании на несколько регионов, поддержка согласованности между хранилищем и кешами - настоящий челлендж.
Для подробностей можно ознакомиться с “Scaling Memcache at Facebook”.&lt;/li&gt;
&lt;li&gt;Политика вытеснения: когда кеш заполнен, любые запросы на добавление элементов в кеш могут вызвать удаление существующих элементов.
Это называется вытеснением кеша.
Least-recently-used (LRU) - в первую очередь, вытесняется неиспользованный дольше всех. Другие политики вытеснения,
такие как Least Frequently Used (LFU) или First in First Out (FIFO) могут быть использованы для соответствия другим требованиям.&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&#34;сеть-доставки-контента-cdn&#34;&gt;Сеть доставки контента (CDN)&lt;/h2&gt;

&lt;p&gt;CDN - сеть географически распределённых серверов, используемая чтобы доставить статический контент.
Сервера CDN кешируют статический контент, такой как изображения, видео, CSS, javascript файлы и т.д.
Кеширование динамического контента - относительно новый концепт и остаётся за рамками этой статьи.
Оно включает в себя кеширование HTML страниц, которое основано на пути запроса, переменных запроса, куках и заголовках запроса.&lt;/p&gt;

&lt;p&gt;Пока фокусируемся на кешировании статического содержимого.&lt;/p&gt;

&lt;p&gt;На рисунке показано, как устроен CDN устроен сверху: когда пользователь посещает вебсайт, CDN сервера, ближайшие к пользователю, доставляют статический контент.
Интуитивно понятно, чем дальше пользователи от серверов CDN, тем дольше грузится сайт.
Например, если CDN сервера в Москве, пользовали из Санкт-Петербурга получат контент быстрее, чем из Владивостока.
Рисунок 1-9 - хороший пример, который показывает как CDN помогает улучшить время загрузки.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-9.png&#34; alt=&#34;Рисунок 1-9&#34; title=&#34;Рисунок 1-9&#34; /&gt;&lt;/p&gt;

&lt;p&gt;На рисунке 1-10 показан процесс работы с CDN&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-10.png&#34; alt=&#34;Рисунок 1-10&#34; title=&#34;Рисунок 1-10&#34; /&gt;&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Пользователь A пытается получить image.png используя URL. URL предоставлен провайдером CDN.
Следующие 2 URL к изображениям - примеры для демонстрации, как выглядят на Amazon или Akami CND:&lt;/li&gt;
&lt;/ol&gt;

&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://mysite.cloudfront.net/logo.jpg&#34; target=&#34;_blank&#34;&gt;https://mysite.cloudfront.net/logo.jpg&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://mysite.akamai.com/image-manager/img/logo.jpg&#34; target=&#34;_blank&#34;&gt;https://mysite.akamai.com/image-manager/img/logo.jpg&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;ol&gt;
&lt;li&gt;Если на CDN сервере нет image.png в кеше, CDN сервер запрашивает файл с источника, который должен быть веб сервером или онлайн хранилищем, похожим на Amazon S3.&lt;/li&gt;
&lt;li&gt;Источник возвращает image.png CDN серверу, включая опциональные HTTP заголовок время жизни (TTL), который описывает, насколько долго кешируется изображение.&lt;/li&gt;
&lt;li&gt;CDN кеширует изображение и возвращает его пользователю A. Изображение остаётся кешированным в СDN, пока не истечёт TTL.&lt;/li&gt;
&lt;li&gt;Пользователь B отправляет запрос на то же изображение.&lt;/li&gt;
&lt;li&gt;Изображение возвращается из кеша, пока TTL не истечёт.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Рекомендации по использованию CDN.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Стоимость: CDN запускаются внешними провайдерами и вы будете платить за доставку входящего и исходящего траффика в CDN.
Кеширование редко используемого контента не даёт значительных преимуществ, поэтому убедитесь, что не используете CDN для таких ресурсов.&lt;/li&gt;
&lt;li&gt;установите подходящее время устаревания кеша: для контента, чувствительного ко времени, установка времени устаревания важна.
Время устаревания должно быть ни слишком маленьким, ни слишком большим.
Если оно будет слишком большим, контент больше не сможет быть свежим.
Если будет слишком маленьким, может вызывать постоянный перезапрос содержимого с источника.&lt;/li&gt;
&lt;li&gt;запасной план к CDN: вы должны подумать, как ваш сайт / приложение справляется с отказом CDN.
Если случится временное отключение CDN, клиенты должны определить проблему и запросить ресурсы с источника.&lt;/li&gt;
&lt;li&gt;Инвалидация файлов: вы можете удалить файл из CND до того как он устарее путём одной из следующих операций:
через API
используя версионирование объектов, например, добавляя в url номер версии image.png?v=2&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Рисунок 1-11 показывает дизайн после добавления CDN и кеша
&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-11.png&#34; alt=&#34;Рисунок 1-11&#34; title=&#34;Рисунок 1-11&#34; /&gt;&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Статические ресурсы (JS, CSS, images, др.,) больше не доставляются веб-сервером. Они доставляются с CDN для лучшей производительности.&lt;/li&gt;
&lt;li&gt;Загрузка базы данных облегчается за счет кеширования данных.&lt;/li&gt;
&lt;/ol&gt;

&lt;h2 id=&#34;сервисы-без-сохранения-состояния-stateless&#34;&gt;Сервисы без сохранения состояния (stateless)&lt;/h2&gt;

&lt;p&gt;Сейчас настало время рассмотреть масштабирование веба горизонтально.
Для этого нам нужно переместить состояние (хранение пользовательских данных) из приложения.
Хорошая практика - это сохранение клиентских сессий во внешнем постоянном хранилище, например, реляционная база данных или NoSQL.
Каждое приложение в кластере должно иметь доступ к этим данным.&lt;/p&gt;

&lt;h2 id=&#34;stateful-архитектура&#34;&gt;Stateful архитектура&lt;/h2&gt;

&lt;p&gt;Statefull север и stateless имеют несколько ключевых различий.
Statefull server запоминает клиентские данные (state, состояние) от одного запроса к другому.
Stateless сервер не хранит информацию о состоянии.&lt;/p&gt;

&lt;p&gt;Рисунок 1-12 показывает пример архитектуры без сохранения состояния.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-12.png&#34; alt=&#34;Рисунок 1-12&#34; title=&#34;Рисунок 1-12&#34; /&gt;&lt;/p&gt;

&lt;p&gt;На рисунке 1-12 сессионные данные и изображение профиля пользователя A сохранены в сервере 1.
Для аутентификации пользователя A HTTP запросы должны быть отправлены на сервер 1. Если запрос будет отправлен на другой сервер,
например сервер 2, аутентификация не сработает, так как сервер 2 не содержит сессионные данные пользователя A.
Аналогично все HTTP запросы от пользователя B должны отправляться на сервер 2. Все запросы от пользователя C должны отправляться на сервер 3.&lt;/p&gt;

&lt;p&gt;Проблема в том, что каждый запрос с одного клиента должен быть отправлен на его сервер.
Технически это может быть сделано с sticky sessions (&amp;ldquo;липкими&amp;rdquo; сессиями) в большинстве балансеров.
Тем не менее, это добавляет лишнюю нагрузку. Добавление или удаление серверов становится труднее.
Также тру&lt;/p&gt;

&lt;p&gt;The issue is that every request from the same client must be routed to the same server. This
can be done with sticky sessions in most load balancers [10]; however, this adds the
overhead. Adding or removing servers is much more difficult with this approach. Также сложно справиться с отказами серверов.&lt;/p&gt;

&lt;h2 id=&#34;stateless-архитектура&#34;&gt;Stateless архитектура&lt;/h2&gt;

&lt;p&gt;Рисунок 1-13 показывает stateless архитектуру.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-13.png&#34; alt=&#34;Рисунок 1-13&#34; title=&#34;Рисунок 1-13&#34; /&gt;&lt;/p&gt;

&lt;p&gt;В stateless архитектуре HTTP запросы от пользователей могут быть отправлены к любому веб-серверу, который получает состояние из общего хранилища данных.
Состояние сохраняется в общем пространстве и содержится отдельно от веб серверов.
Stateless система проще, более надёжна и масштабируема.&lt;/p&gt;

&lt;p&gt;Рисунок 1-14 показывает обновлённый дизайн с приложениями без сохранения состояния.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-14.png&#34; alt=&#34;Рисунок 1-14&#34; title=&#34;Рисунок 1-14&#34; /&gt;&lt;/p&gt;

&lt;p&gt;На рисунке 1-14 мы перемещаем сессионные данные из веб серверов и сохраняем их в постоянном хранилище.
Общие хранилища данных могут быть реляционными базами, Memcached / Redis, NoSQL и другими.
Хранилище NoSQL выбирается для упрощения масштабирования.
Автомасштабирование означает добавление или удаление серверов, основанное на показателях нагрузки.
После того как состояние перемещено из зоны приложений, автомасштабирование приложений достигается легко путём добавления или удаления серверов, основанное на загрузке по траффику.&lt;/p&gt;

&lt;p&gt;Ваш вебсайт растёт быстро и привлекает значительное количество международных пользователей.
Чтобы улучшить доступность и предоставить лучший пользовательский опыт по всем географическим районам,
добавим поддержку нескольких центров обработки данных.&lt;/p&gt;

&lt;h2 id=&#34;data-centers&#34;&gt;Data centers&lt;/h2&gt;

&lt;p&gt;Рисунок 1-15 показывает пример настройки с двумя датацентрами. В нормальном режиме пользователи маршрутизированы средствами geoDNS
к ближайшему датацентру, с делением траффика x% в US-East и (100 - x)% в US-West. geoDNS - это DNS сервис, который разрешает доменные имена
в их IP адреса в соответствии с их местоположением.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-15.png&#34; alt=&#34;Рисунок 1-15&#34; title=&#34;Рисунок 1-15&#34; /&gt;&lt;/p&gt;

&lt;p&gt;В случае значительного отказа датацентра, мы перенаправим весь траффик к живому датацентру.
На рисунке 1-16 датацентра 2 (US-West) оффлайн и 100% траффика маршрутизировано к здоровому дата центру 1 (US-East).&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/scaling-from-zero-to-millions-of-users/figure1-16.png&#34; alt=&#34;Рисунок 1-16&#34; title=&#34;Рисунок 1-16&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Несколько технических вызовов должны быть решены для достижения развёртывания на несколько датацентров:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;Переадресация траффика: для перенаправления траффика в нужный датацентр нужны эффективные инструменты. GeoDNS может быть использован, но мы не можем оперативно управлять DNS на клиенте. Если у вас есть возможность, используйте BGP для анонса нескольких IP адресов.&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Синхронизация данных: пользователи из разных регионов могут использовать разные локальные базы данных или кеши.
В случаях аварийного переключения траффик может быть перенаправлен в датацентр, в котором данные недоступны.
Общая стратегия - это репликация данных на несколько датацентров.&lt;/p&gt;&lt;/li&gt;

&lt;li&gt;&lt;p&gt;Тесты и развёртывание: с конфигурацией в несколько датацентров важно проверять ваше приложение с разных локаций.
Инструменты автоматического развёртывания жизненно необходимы для поддержки сервисов в консистентном состоянии во всех датацентрах.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Для дальнейшего масштабирования системы нам нужно расцепить разные компоненты, чтобы масштабировать их независимо.
Очередь сообщений - ключевая стратегия, применяемая многими мировыми распределёнными системами для решения этих проблем.&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Системный дизайн, простой уровень</title>
      <link>https://vitalyzhakov.github.io/post/system-design-easy/</link>
      <pubDate>Fri, 01 Oct 2021 00:10:06 +0500</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/system-design-easy/</guid>
      <description>

&lt;p&gt;Рассмотрим в качестве простого примера сервис, доставляющий статическую веб страницу.&lt;/p&gt;

&lt;p&gt;Факторами оценки могут быть:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;SL доступности сервиса;&lt;/li&gt;
&lt;li&gt;Время ответа на запрос клиента;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;В самом простом варианте клиенты размещены в Москве.&lt;/p&gt;

&lt;p&gt;Ограничения&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;SL виртуальной машины (SLвм) = 99.95&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Допущения&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;мы в состоянии сделать сервис доставки страниц идеальным;&lt;/li&gt;
&lt;li&gt;нагрузкой на сервис пока пренебрежём.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Пусть сервис размещён в PRM.&lt;/p&gt;

&lt;p&gt;Считаем факторы оценки&lt;/p&gt;

&lt;p&gt;SL сервиса ~ SL nginx * SL вм, что примерно равно SL вм = 99.95&lt;/p&gt;

&lt;p&gt;Время ответа = время генерации страницы (~1 msec) + время доставки до Москвы (~20 msec).
Итого 21 msec.&lt;/p&gt;

&lt;h2 id=&#34;география&#34;&gt;География&lt;/h2&gt;

&lt;p&gt;Усложним задачу.&lt;/p&gt;

&lt;p&gt;30% клиентов в Москве,
40% клиентов в Перми,
30% клиентов в Омске.&lt;/p&gt;

&lt;p&gt;Тогда время доставки будет выглядеть как взвешенная сумма&lt;/p&gt;

&lt;p&gt;Время доставки = 0,3 * 20 * 0,4 * 5 * 0,3 * 30 = 17&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Схема CI/CD  для веб-разработчиков на основе open-source инструментов</title>
      <link>https://vitalyzhakov.github.io/post/ci-cd/</link>
      <pubDate>Mon, 22 Mar 2021 00:10:06 +0500</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/ci-cd/</guid>
      <description>


&lt;div style=&#34;position: relative; padding-bottom: 56.25%; padding-top: 30px; height: 0; overflow: hidden;&#34;&gt;
  &lt;iframe src=&#34;//www.youtube.com/embed/ODo3QieLvA8&#34; style=&#34;position: absolute; top: 0; left: 0; width: 100%; height: 100%;&#34; allowfullscreen frameborder=&#34;0&#34; title=&#34;YouTube Video&#34;&gt;&lt;/iframe&gt;
 &lt;/div&gt;


&lt;p&gt;Содержание&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Общая схема&lt;/li&gt;
&lt;li&gt;Сервер dev с песочницами&lt;/li&gt;
&lt;li&gt;Детализация разработки (создание ветки, непрерывный деплой и тестирование, создание merge на бота, апрув в master)&lt;/li&gt;
&lt;li&gt;Прод с master-master репликацией, graylog, sentry, prometheus.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Наверное, все видели стандартную восьмёрку, как выглядит CI/CD:&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/ci-cd/8.png&#34; alt=&#34;Бесконечность CI/CD&#34; title=&#34;Бесконечность CI/CD&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Но обычно никто не рассказывает, как именно реализовать этот процесс.&lt;/p&gt;

&lt;p&gt;Сегодня детализирую этот на примере разработки веб-сервисов.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/ci-cd/common-scheme.png&#34; alt=&#34;Общая схема&#34; title=&#34;Общая схема&#34; /&gt;&lt;/p&gt;

&lt;p&gt;На схеме мы видим, как параллельно сдаются задачи (в виде коммитов) в master-ветку.&lt;/p&gt;

&lt;p&gt;Далее принимается решение о релизе, он фиксируется, отправляется в &lt;em&gt;registry&lt;/em&gt; (магазин приложений),
с &lt;em&gt;registry&lt;/em&gt; готовое приложение попадает в прод.
Некоторое время за ним следим (в sentry) на наличие новых ошибок.
При возникновении потребности в откате - возвращаем на предыдущий тег из gitlab environments.&lt;/p&gt;

&lt;p&gt;Далее поэтапно рассмотрим реализацию каждого шага.&lt;/p&gt;

&lt;p&gt;Сердцем всей истории у нас является Gitlab и Gitab-CI.&lt;/p&gt;

&lt;p&gt;Git flow показался нам слишком сложным для поддержки из одного репозитория одного проекта на продакшне.
&lt;a href=&#34;https://guides.github.com/introduction/flow/index.html&#34; target=&#34;_blank&#34;&gt;Github flow&lt;/a&gt; до слияния в master релизит изменения на пользователей (прод).
Параллельность работы нескольких разработчиков остаётся не раскрытой.&lt;/p&gt;

&lt;p&gt;История с production/preproduction веткой в &lt;a href=&#34;https://docs.gitlab.com/ee/topics/gitlab_flow.html&#34; target=&#34;_blank&#34;&gt;Gitlab flow&lt;/a&gt; также кажется нам лишней, поэтому предлагаем вам следующую схему:&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/ci-cd/tank.png&#34; alt=&#34;Flow&#34; title=&#34;Flow&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Схема поддерживает наличие нескольких разработчиков, работающих над проектом.
На схеме видно, что разработка фичей идёт в неблокирующем режиме.
На самом деле одного gitlab не достаточно, чтобы это работало. Грамотная архитектура проекта (кодовой базы) позволяет избежать конфликтов при разработке, что благоприятно влияет на TTM фичи. Также важно, чтобы сервис соответствовал архитектурным принципам (например, &lt;a href=&#34;https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%B5%D0%B4%D0%B8%D0%BD%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE%D0%B9_%D0%BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8&#34; target=&#34;_blank&#34;&gt;SRP&lt;/a&gt;). Ответственность должна быть полностью инкапсулирована в сервис.&lt;/p&gt;

&lt;p&gt;Из факта, что большинство ошибок возникают из-за внесения изменений, следует, что максимальное внимание нужно уделить именно изменению, а именно:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;ветка для разработки фичи максимально соответствовала проду (подход управления всем через код вам в помощь);&lt;/li&gt;
&lt;li&gt;тестировать изменение;&lt;/li&gt;
&lt;li&gt;проводить статический анализ и другие автоматические проверки максимально близко к изменению;&lt;/li&gt;
&lt;li&gt;проводить code review;&lt;/li&gt;
&lt;li&gt;по возможности наиболее строго относиться к ошибкам компилятора, интерпретаторов SQL-запросов и т.д.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Если пускать в master нестабильные изменения, разработка параллельных фич может забрать их себе и при тестировании посчитать багом, привнесённым своей фичей. Всё это может сказаться отрицательно на TTM.
Поэтому важно &lt;code&gt;держать master стабильным&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;Процесс &lt;code&gt;code review&lt;/code&gt; является затратным как с точки зрения фактических затрат времени, так и временного промежутка, который отдаляет фичу от master.
В большом коллективе важно, чтобы правила проведения review были приняты всей командой и были объективными.
Технические мероприятие для снижения длительности:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;автоматизация проведения проверок CI вместо человека;&lt;/li&gt;
&lt;li&gt;автоматическое распределение review между проверяющими;&lt;/li&gt;
&lt;li&gt;автоматическая очередь мерждей после прохождения всех стадий контроля.&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&#34;dev-сервер-с-песочницами-под-каждую-ветку&#34;&gt;Dev-сервер с песочницами под каждую ветку&lt;/h2&gt;

&lt;h3 id=&#34;в-начале-были-виртуалки-на-сервис&#34;&gt;В начале были виртуалки на сервис&lt;/h3&gt;

&lt;ul&gt;
&lt;li&gt;отдел, разрабатывающий код (Dev);&lt;/li&gt;
&lt;li&gt;отдел, поддерживающий прод (Ops);&lt;/li&gt;
&lt;li&gt;Ops предоставляли Dev виртуалку - копию прода. Но как только 2 разработчика начинали дорабатывать один сервис
через SFTP, они перезаписывали код друг друга;&lt;/li&gt;
&lt;li&gt;на проде возможно обновить только код, системный софт - невозможно (из-за трудностей с тестированием и параллельного внесения изменений).&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&#34;затем-виртуалки-с-пушем-через-svn&#34;&gt;Затем виртуалки с пушем через SVN&lt;/h3&gt;

&lt;ul&gt;
&lt;li&gt;они всегда были заняты;&lt;/li&gt;
&lt;li&gt;они всегда были сломаны;&lt;/li&gt;
&lt;li&gt;часто не соответствовали продакшну;&lt;/li&gt;
&lt;li&gt;новая виртуалка ~ 2 недели ожидания.&lt;/li&gt;
&lt;li&gt;копирование файлов вручную на прод приводило к багам;&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&#34;теперь-у-нас-dev-сервер-с-песочницами-под-каждую-ветку&#34;&gt;Теперь у нас Dev-сервер с песочницами под каждую ветку&lt;/h3&gt;

&lt;p&gt;Основная фишка - предоставление песочницы под задачу со всеми нужными контейнерами для разработки быстро (в идеале в течение 1 минуты после запроса).
Сервис в песочнице должен максимально повторять продакшн.&lt;/p&gt;

&lt;p&gt;Понятно, что железо стоит денег, поэтому старые песочницы ночью удаляются в автоматическом режиме.
Для увеличения порядка ветки, которые не прошли проверку временем, по истечению таймаута нужно удалять.
Иначе многие будут хотеть воскресить старую разработку, которая не актуальна не только по качеству кода, но и догнать master будет стоить значительного времени.&lt;/p&gt;

&lt;p&gt;Без этой операции при большом количестве параллельных задач можно погрязнуть в хаосе.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/ci-cd/devScheme-docker.png&#34; alt=&#34;Схема работы dev-сервера&#34; title=&#34;Схема работы dev-сервера&#34; /&gt;
&lt;img src=&#34;https://vitalyzhakov.github.io/images/ci-cd/gitlabRunner.png&#34; alt=&#34;Схема работы dev-сервера&#34; title=&#34;Схема работы dev-сервера&#34; /&gt;&lt;/p&gt;

&lt;p&gt;На этой картинке показано, что пользователи сервиса заходят через nginx на конкретную песочницу,
которая регистрируется в nginx во время создания с помощью consul и consul-template.&lt;/p&gt;

&lt;p&gt;Задания исполняются с помощью gitlab-ci&lt;/p&gt;

&lt;p&gt;Первое задание - сборка образа&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;Build Dev Image:
  stage: build_dev_image
    - docker build --tag ${IMAGE_ADDRESS} .
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Второе задание - запуск сервиса&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;Deploy dev:
  stage: deploy_dev
  script:
    # Для веб-сервисов нужен FQDN
    - export FQDN=task-123.project.team.dev
    - docker-compose up -d
    - consul-template -config consul.conf
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Пример содержимого файла docker-compose&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-yaml&#34;&gt;version: &#39;2.3&#39;
services:
    web:
        image: ${IMAGE_ADDRESS}
        container_name: ${COMPOSE_PROJECT_NAME}
        depends_on:
            - mongo
        network_mode: &amp;quot;bridge&amp;quot;
        environment:
            SERVICE_NAME: ${COMPOSE_PROJECT_NAME}
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;4-прод-с-master-master-репликацией-graylog-sentry-prometheus&#34;&gt;4. Прод с master-master репликацией, graylog, sentry, prometheus&lt;/h2&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/ci-cd/prod.png&#34; alt=&#34;Prod&#34; title=&#34;Prod&#34; /&gt;&lt;/p&gt;

&lt;p&gt;На продакшне у нас развёрнуты kubernetes-кластера в двух географически распределённых ЦОДах.
Kubernetes сейчас стандарт де-факто. DB, файлы реплицируются в обе стороны.
Поддерживает IaaC (Infrastructure as a Code), что позволяет прямо в ветке внести изменения,
которые с релизом уйдут на прод. Сервисы ограничены лимитами k8s, что исключает негативное воздействие одного сервиса на другой.&lt;/p&gt;

&lt;p&gt;Географическое active-active распределение помогает нам снизить сетевые задержки до клиентов и
позволяет иметь горячий бекап, куда можно переключиться при проведении работ или аварии на одном из кластеров.&lt;/p&gt;

&lt;p&gt;С другой стороны, это достаточно дорого обходится нам (приходится писать софт соответствующим образом).&lt;/p&gt;

&lt;p&gt;Не всем это нужно, вполне можно обойтись одним кластером.&lt;/p&gt;

&lt;p&gt;Контейнеры созданы по методологии 12-факторного приложения, один из пунктов которого гласит - пишите логи в стандартный вывод.
Затем они подхватываются и отправляются в graylog (можно с таким же успехом взять ELK), где можно посмотреть логи.&lt;/p&gt;

&lt;p&gt;Ошибки пишутся в sentry, при релизах просматриваются на предмет появления новых.
Если в случае с graylog при ограниченном бюджете на железо ещё можно подумать о его необходимости,
то для sentry не нужно много ресурсов, если вы будете своевременно устранять ошибки, которые записали.
Это скажется благоприятно как на качестве приложения, так и на затратах железа на sentry.
Ещё раз повторюсь, не так важно писать ошибки в sentry, как важно их разбирать и устранять.&lt;/p&gt;

&lt;p&gt;Метрики приложений отправляются в prometheus, который в состоянии отреагировать на стандартные проблемы с сервисами. Резерв при пороговых триггерах - простой способ узнать о надвигающемся инциденте заранее и предотвратить его.&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Исключения и библиотеки</title>
      <link>https://vitalyzhakov.github.io/post/exception-in-libs/</link>
      <pubDate>Thu, 11 Feb 2021 00:00:00 +0000</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/exception-in-libs/</guid>
      <description>&lt;p&gt;При создании библиотек часто возникает вопрос,
прокидывать исключение наружу или ловить его в библиотеке?&lt;/p&gt;

&lt;p&gt;Ответ прост)&lt;/p&gt;

&lt;p&gt;Если библиотека знает, как поступить с исключением, стоит обработать его в библиотеке.&lt;/p&gt;

&lt;p&gt;Если библиотека не знает, как поступить с исключением, стоит отдать обработку на уровень выше (в другую библиотеку или приложение).&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Исправляем ошибку fxp/composer-asset-plugin incompatible после обновления до composer 2</title>
      <link>https://vitalyzhakov.github.io/post/composer-2-fxp-asset-plugin/</link>
      <pubDate>Sat, 02 Jan 2021 00:10:06 +0500</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/composer-2-fxp-asset-plugin/</guid>
      <description>

&lt;p&gt;После обновления менеджера пакетов PHP composer до версии 2 появляется ошибка:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;  [RuntimeException]                                                                                    
  No composer.json present in the current directory, this may be the cause of the following exception.

  [InvalidArgumentException]
  Package fxp/composer-asset-plugin at version has a PHP requirement incompatible with your PHP version, PHP extensions and Composer version 
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Происходит из-за несовместимости fxp/composer-asset-plugin и composer версии 2.&lt;/p&gt;

&lt;h2 id=&#34;решение&#34;&gt;Решение&lt;/h2&gt;

&lt;p&gt;Удаляем старый плагин&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;composer global remove fxp/composer-asset-plugin
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Если появляется ошибка, связанная с папками bower или npm,
добавляем в config.php приложения алиасы до соответствующих папок&lt;/p&gt;

&lt;p&gt;Пример ошибки&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;mito/yii2-sentry[1.0.0, ..., 1.0.2] require bower-asset/raven-js
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code class=&#34;language-php&#34;&gt;&#39;modules&#39; =&amp;gt; [ ... ],
&#39;aliases&#39; =&amp;gt; [
    &#39;@bower&#39; =&amp;gt; &#39;@vendor/bower-asset&#39;,
    &#39;@npm&#39; =&amp;gt; &#39;@vendor/npm-asset&#39;,
],
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;В composer.json добавляем&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;repositories&amp;quot;: [
    {
        &amp;quot;type&amp;quot;: &amp;quot;composer&amp;quot;,
        &amp;quot;url&amp;quot;: &amp;quot;https://asset-packagist.org&amp;quot;
    }
]
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Удаляем остатки fxp-asset (если есть):&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-json&#34;&gt;&amp;quot;config&amp;quot;: {
    &amp;quot;fxp-asset&amp;quot;: {
        &amp;quot;installer-paths&amp;quot;: {
            &amp;quot;npm-asset-library&amp;quot;: &amp;quot;vendor/npm&amp;quot;,
            &amp;quot;bower-asset-library&amp;quot;: &amp;quot;vendor/bower&amp;quot;
        }
    }
}
&lt;/code&gt;&lt;/pre&gt;
</description>
    </item>
    
    <item>
      <title>Оптимизация обращений к базе данных</title>
      <link>https://vitalyzhakov.github.io/post/db-optimization/</link>
      <pubDate>Fri, 25 Dec 2020 00:10:06 +0500</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/db-optimization/</guid>
      <description>

&lt;p&gt;При разборе времени генерации ответа от сервера иногда узким местом может быть обращение к СУБД.
Оптимизацию времени доступа к СУБД можно разделить на несколько видов:&lt;/p&gt;

&lt;h2 id=&#34;использование-параметризованных-запросов&#34;&gt;Использование параметризованных запросов&lt;/h2&gt;

&lt;p&gt;Некоторые программисты совершают ошибку, вписывая параметры (например, идентификаторы) запроса сразу в запрос.
Первым шагом СУБД пытается проанализировать запрос. Если параметры приходят в запросе, в кеш запрос не складывается.
Но если параметры прикладывать к запросу, структура запроса не меняется.
Значит, при следующем запросе, есть вероятность нахождения проанализированной структуры в кеше, что позволит ускорить выполнение.&lt;/p&gt;

&lt;h2 id=&#34;размещение-приложения-ближе-к-субд&#34;&gt;Размещение приложения &amp;ldquo;ближе&amp;rdquo; к СУБД&lt;/h2&gt;

&lt;p&gt;Улучшение сетевой связности может положительно сказаться на производительности приложения в целом,
при этом вам не обязательно вносить изменения в код.&lt;/p&gt;

&lt;h2 id=&#34;использование-постоянных-соединений&#34;&gt;Использование постоянных соединений&lt;/h2&gt;

&lt;p&gt;Обычно поднятие соединений занимает значительное количество ресурсов СУБД.
Для исполнения одних и тех же запросов не обязательно поднимать каждый раз новое соединение, можно переиспользовать.
Например, в php это можно сделать одним атрибутом соединения &lt;a href=&#34;https://www.php.net/manual/ru/features.persistent-connections.php&#34; target=&#34;_blank&#34;&gt;https://www.php.net/manual/ru/features.persistent-connections.php&lt;/a&gt;&lt;/p&gt;

&lt;h2 id=&#34;написание-хранимых-процедур&#34;&gt;Написание хранимых процедур&lt;/h2&gt;

&lt;p&gt;Порог входа для написания хранимых процедур достаточно высок.
Но если проект высоко нагружен и все остальные способы оптимизации вы уже перебрали, стоит попробовать.&lt;/p&gt;

&lt;p&gt;Несколько запросов, зависящих друг от друга, можно объединить таким способом и
снизить затраты на сетевой обмен между сервером приложений и сервером баз данных.&lt;/p&gt;

&lt;h2 id=&#34;оптимизация-запросов-и-расстановка-индексов&#34;&gt;Оптимизация запросов и расстановка индексов&lt;/h2&gt;

&lt;p&gt;Здесь подразумевается использование инструментов &lt;code&gt;MySQL SLOW LOG&lt;/code&gt;, &lt;code&gt;explain&lt;/code&gt;.&lt;/p&gt;

&lt;h3 id=&#34;убираем-лишние-таблицы-данные-из-запросов&#34;&gt;Убираем лишние таблицы / данные из запросов&lt;/h3&gt;

&lt;p&gt;Стоит свежим взглядом осмотреть запросы не предмет неиспользуемых таблиц/полей в запросах.
Это может дать значительный эффект в проект, в который частно вносятся изменения, но при этом рефакторинга
&amp;ldquo;на свежую голову&amp;rdquo; давно не было.&lt;/p&gt;

&lt;h3 id=&#34;расстановка-индексов&#34;&gt;Расстановка индексов&lt;/h3&gt;

&lt;p&gt;Индексы добавляют размера базе данных, но позволяют ускорить запросы.
Стоит поискать баланс с помощью &lt;code&gt;EXPLAIN&lt;/code&gt;.&lt;/p&gt;

&lt;h2 id=&#34;денормализация-и-объединение-запросов&#34;&gt;Денормализация и объединение запросов&lt;/h2&gt;

&lt;p&gt;Этот вариант требует значительных затрат и модификации.
В большинстве систем данные нормализованы для поддержания целостности.
Но с точки зрения оптимизации времени выборка из одной таблицы обходится дешевле, чем связка нескольких и выборка из связки.&lt;/p&gt;

&lt;h2 id=&#34;поиск-аномалий&#34;&gt;Поиск аномалий&lt;/h2&gt;

&lt;p&gt;Иногда стоит взглянуть на полный лог SQL-запросов, чтобы понять действительное положение вещей.
Может казаться, что узкое место - одно, а на самом деле - другое (например, приложение генерит много UPDATE, хотя не должно).
В случае с docker-compose можно сделать так:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-yaml&#34;&gt;version: &#39;2.3&#39;
services:
    mysql:
        image: &#39;percona:8.0&#39;
        command:
            - --general-log=1
            - --general-log-file=/tmp/general.log
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Далее просмотреть содержимое файла &lt;code&gt;/tmp/general.log&lt;/code&gt;.&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Устранение ошибок SQL запросов в режиме ONLY_FULL_GROUP_BY</title>
      <link>https://vitalyzhakov.github.io/post/mysql-only-full-group-by/</link>
      <pubDate>Wed, 16 Sep 2020 00:10:06 +0500</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/mysql-only-full-group-by/</guid>
      <description>

&lt;blockquote&gt;
&lt;p&gt;“Что случилось с моим приложением? Я установил новую версию MySQL. Запросы, что выполнялись на старой версии теперь падают с кучей ошибок.&amp;rdquo;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Многие программисты сталкиваются с этим вопросом при обновлении до версий 5.7 или 8.
В этой статье мы рассмотрим один из самых частых кейсов и его решение.&lt;/p&gt;

&lt;p&gt;Мы говорим об этой ошибке&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-SQL&#34;&gt;ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause 
and contains nonaggregated column &#39;test.web_log.user_id&#39; which is not functionally 
dependent on columns in GROUP BY clause; this is incompatible 
with sql_mode=only_full_group_by
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Видели ли вы когда-либо её?&lt;/p&gt;

&lt;h2 id=&#34;sql-mode&#34;&gt;SQL_MODE&lt;/h2&gt;

&lt;p&gt;Для начала разрешите мне представить концепцию &lt;em&gt;SQL_MODE&lt;/em&gt;.&lt;/p&gt;

&lt;p&gt;MySQL может работать используя разные SQL режимы, которые влияют
на синтаксис запросов и валидацию.
В зависимости от установленного значения переменной sql_mode
запрос может быть валидным и выполняться или может получить
ошибку валидации и не может быть выполнен.&lt;/p&gt;

&lt;p&gt;Старейшие версии MySQL научили пользователей писать запросы, которые
семантически корректны, потому что разработаны для работы в “прощающем режиме”.
Пользователи могли писать любой синтаксически правильный запрос независимо от
соответствия SQL стандарту или сематических правил.&lt;/p&gt;

&lt;p&gt;Это была плохая привычка, которая была исправлена введением sql_mode, чтобы настроить MySQL
работать более строгим способом для проверки запросов.&lt;/p&gt;

&lt;p&gt;Некоторые пользователи не знают об этой функции, потому что значение по умолчанию не было таким строгим. Начиная с версии 5.7, значение по умолчанию является более строгим, и по этой причине у некоторых пользователей возникают проблемы с неожиданными ошибками запросов после перехода на 5.7 или 8.0.&lt;/p&gt;

&lt;p&gt;Переменная &lt;em&gt;sql_mode&lt;/em&gt; может быть установлена в файле конфигурации (/etc/my.cnf) или
может быть изменена во время выполнения.
Область действия переменной может быть GLOBAL или SESSION, поэтому может измениться
в соответствии с целью для любого отдельного соединения.&lt;/p&gt;

&lt;p&gt;Переменная sql_mode может иметь несколько значений, разделённых запятой, для настройки различных поведений.
Например, вы можете проинструктировать MySQL как обращаться с датами с нулями, как &lt;code&gt;0000-00-00&lt;/code&gt;,
чтобы дата считалась действительной или нет.&lt;/p&gt;

&lt;p&gt;В &amp;ldquo;прощающем режиме&amp;rdquo; (или если переменная sql_mode пуста), вы можете вставить такое значение без проблем.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-SQL&#34;&gt;# установка sql в &amp;quot;прощающий режим&amp;quot; 
mysql&amp;gt; set session sql_mode=&#39;&#39;;
Query OK, 0 rows affected (0.00 sec)

mysql&amp;gt; create table t1( mydate date );
Query OK, 0 rows affected (0.05 sec)

mysql&amp;gt; insert into t1 values(&#39;0000-00-00&#39;);
Query OK, 1 row affected (0.00 sec)

mysql&amp;gt; select * from t1;
+------------+
| mydate     |
+------------+
| 0000-00-00 |
+------------+
1 row in set (0.00 sec)
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Но это не правильное поведение, как заявлено в режиме TRADITIONAL.
Как хорошие программисты знают, что нужно проверять даты
в коде приложения, чтобы избежать некорректных данных или некорректных результатов.&lt;/p&gt;

&lt;p&gt;Далее мы показываем, как динамически проинструктировать MySQL вести себя в traditional режиме,
чтобы выбросить исключений вместо замалчивания ошибки:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-SQL&#34;&gt;mysql&amp;gt; set session sql_mode=&#39;TRADITIONAL&#39;;
Query OK, 0 rows affected (0.00 sec)

mysql&amp;gt; insert into t1 values(&#39;0000-00-00&#39;);
ERROR 1292 (22007): Incorrect date value: &#39;0000-00-00&#39; for column &#39;mydate&#39; at row 1
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Существует множество режимов, которые вы можете использовать.
Покрытие всех режимов - не цель данной статьи, поэтому обратитесь
к &lt;a href=&#34;https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html&#34; target=&#34;_blank&#34;&gt;официальной документации&lt;/a&gt;
за подробностями и примерами.&lt;/p&gt;

&lt;h2 id=&#34;проблема-only-full-group-by&#34;&gt;Проблема ONLY_FULL_GROUP_BY&lt;/h2&gt;

&lt;p&gt;Давайте сосредоточимся на самом частом кейсе ошибок миграции с 5.7 на 8.0.
Как уже было сказано, в 5.7 более строгий режим, чем в 5.6, в 8.0 более строгий, чем в 5.7.&lt;/p&gt;

&lt;p&gt;Это работает, если вы обновляете MySQL, копируя старый файл my.cnf,
который не имеет специфичных настроек для переменной sql_mode. Итак, имейте в виду.&lt;/p&gt;

&lt;p&gt;Давайте создадим простую таблицу для хранения кликов на вебстраницах нашего сайта.
Мы будем записывать название страницы и ID зарегистрированного пользователя.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-SQL&#34;&gt;mysql&amp;gt; create table web_log ( id int auto_increment primary key, page_url varchar(100), user_id int, ts timestamp);
Query OK, 0 rows affected (0.03 sec)

mysql&amp;gt; insert into web_log(page_url,user_id,ts) values(&#39;/index.html&#39;,1,&#39;2019-04-17 12:21:32&#39;),
    -&amp;gt; (&#39;/index.html&#39;,2,&#39;2019-04-17 12:21:35&#39;),(&#39;/news.php&#39;,1,&#39;2019-04-17 12:22:11&#39;),(&#39;/store_offers.php&#39;,3,&#39;2019-04-17 12:22:41&#39;),
    -&amp;gt; (&#39;/store_offers.php&#39;,2,&#39;2019-04-17 12:23:04&#39;),(&#39;/faq.html&#39;,1,&#39;2019-04-17 12:23:22&#39;),(&#39;/index.html&#39;,3,&#39;2019-04-17 12:32:25&#39;),
    -&amp;gt; (&#39;/news.php&#39;,2,&#39;2019-04-17 12:32:38&#39;);
Query OK, 7 rows affected (0.01 sec)
Records: 7  Duplicates: 0  Warnings: 0

mysql&amp;gt; select * from web_log;
+----+--------------------+---------+---------------------+
| id | page_url           | user_id | ts                  |
+----+--------------------+---------+---------------------+
|  1 | /index.html        |       1 | 2019-04-17 12:21:32 |
|  2 | /index.html        |       2 | 2019-04-17 12:21:35 |
|  3 | /news.php          |       1 | 2019-04-17 12:22:11 |
|  4 | /store_offers.php  |       3 | 2019-04-17 12:22:41 |
|  5 | /store_offers.html |       2 | 2019-04-17 12:23:04 |
|  6 | /faq.html          |       1 | 2019-04-17 12:23:22 |
|  7 | /index.html        |       3 | 2019-04-17 12:32:25 |
|  8 | /news.php          |       2 | 2019-04-17 12:32:38 |
+----+--------------------+---------+---------------------+
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Теперь мы хотим написать запрос для подсчёта наиболее посещаемых страниц сайта&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-SQL&#34;&gt;mysql&amp;gt; set session sql_mode=&#39;&#39;;
Query OK, 0 rows affected (0.00 sec)

mysql&amp;gt; SELECT page_url, user_id, COUNT(*) AS visits
    -&amp;gt; FROM web_log
    -&amp;gt; GROUP BY page_url ORDER BY COUNT(*) DESC;
+-------------------+---------+--------+
| page_url          | user_id | visits |
+-------------------+---------+--------+
| /index.html       |       1 |      3 |
| /news.php         |       1 |      2 |
| /store_offers.php |       3 |      2 |
| /faq.html         |       1 |      1 |
+-------------------+---------+--------+
4 rows in set (0.00 sec)
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Этот запрос работает, но на самом деле не корректен.
Легко понять, что page_url - столбик для группировки, значение, которое нас больше всего интересует
и мы хотим, чтобы оно было уникальным для подсчёта.
Также столбик visits понятен, это счётчик. Но как насчёт user_id?
Что представляет эта колонка?
Мы сгруппировали по page_url, поэтому значение, возвращаемое для user_id - только одно из значений в группе.
Фактически не только пользователь номер 1 посетил index.html, но также пользователи 2 и 3 посетили эту страницу.
Как нам интерпретировать значение? Это первый посетитель? Или последний?&lt;/p&gt;

&lt;p&gt;Мы не знаем правильного ответа!
Мы должны рассматривать значение колонки user_id как случайный элемент из группы.&lt;/p&gt;

&lt;p&gt;В любом случае, правильный ответ - запрос семантически некорректен,
так как нет смысла для возвращаемого значения столбика, что не является частью функции группировки.
Запрос будет недействительным в традиционном SQL.&lt;/p&gt;

&lt;p&gt;Давайте проверим это&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-SQL&#34;&gt;mysql&amp;gt; SET SESSION sql_mode=&#39;ONLY_FULL_GROUP_BY&#39;;
Query OK, 0 rows affected (0.00 sec)

mysql&amp;gt; SELECT page_url, user_id, COUNT(*) AS visits 
    -&amp;gt; FROM web_log 
    -&amp;gt; GROUP BY page_url ORDER BY COUNT(*) DESC;
ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause 
and contains nonaggregated column &#39;test.web_log.user_id&#39; which is not functionally 
dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Как и ожидалось, у нас ошибка.&lt;/p&gt;

&lt;p&gt;Режим SQL &lt;em&gt;ONLY_FULL_GROUP_BY&lt;/em&gt; - это часть &lt;em&gt;TRADITIONAL&lt;/em&gt; режима и включен по умолчанию
начиная с 5.7.&lt;/p&gt;

&lt;p&gt;Множество программистов столкнулось с разновидностью этой ошибки после миграции на последнюю версию
MySQL.&lt;/p&gt;

&lt;p&gt;Теперь мы знаем, что вызывает эту ошибку, но наше приложение всё ещё не работает.
Какие возможные решения у нас есть, чтобы вернуть приложение к работе?&lt;/p&gt;

&lt;h2 id=&#34;решение-1-переписать-запрос&#34;&gt;Решение 1 - переписать запрос&lt;/h2&gt;

&lt;p&gt;Так как не корректно выбирать колонку, которая не является частью группировки,
мы можем переписать запрос без этой колонки. Очень просто.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-SQL&#34;&gt;mysql&amp;gt; SELECT page_url, COUNT(*) AS visits
    -&amp;gt; FROM web_log
    -&amp;gt; GROUP BY page_url ORDER BY COUNT(*) DESC;
+-------------------+--------+
| page_url          | visits |
+-------------------+--------+
| /index.html       |      3 |
| /news.php         |      2 |
| /store_offers.php |      2 |
| /faq.html         |      1 |
+-------------------+--------+
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Если много ваших запросов затронуты проблемой, вы можете потенциально сделать много работы,
чтобы найти и переписать их.
Или, возможно, проблемные запросы - часть старого приложения, которое нет возможности изменить.&lt;/p&gt;

&lt;p&gt;Но это решение заставляет вас писать правильные запросы и пусть конфигурация вашей базы данных
проверяет на такие ошибки в терминах SQL-валидации.&lt;/p&gt;

&lt;h2 id=&#34;решение-2-вернуть-прощающий-режим&#34;&gt;Решение 2 - вернуть &amp;ldquo;прощающий режим&amp;rdquo;&lt;/h2&gt;

&lt;p&gt;Вы можете поменять конфигурацию подключения или MySQL сервера и вернуть &amp;ldquo;прощающий&amp;rdquo; режим.&lt;/p&gt;

&lt;p&gt;Или вы можете убрать только &lt;em&gt;ONLY_FULL_GROUP_BY&lt;/em&gt; из настроек по умолчанию.
По умолчанию SQL режим в 5.7 включает режимы: ONLY_FULL_GROUP_BY, STRINCT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-SQL&#34;&gt;#set the complete &amp;quot;forgiving&amp;quot; mode
mysql&amp;gt; SET GLOBAL sql_mode=&#39;&#39;;

# alternatively you can set sql mode to the following
mysql&amp;gt; SET GLOBAL sql_mode=&#39;STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_ENGINE_SUBSTITUTION&#39;;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Для yii2-приложения конфиг может выглядеть так:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-php&#34;&gt;&amp;lt;?php

return [
    &#39;class&#39; =&amp;gt; &#39;yii\db\Connection&#39;,
    &#39;dsn&#39; =&amp;gt; &#39;mysql:host=&#39; . getenv(&#39;MYSQL_HOST&#39;) . &#39;;port=&#39; . getenv(&#39;MYSQL_PORT&#39;) . &#39;;dbname=&#39; . getenv(&#39;MYSQL_DB&#39;),
    &#39;username&#39; =&amp;gt; getenv(&#39;MYSQL_USER&#39;),
    &#39;password&#39; =&amp;gt; getenv(&#39;MYSQL_PASSWORD&#39;),
    &#39;charset&#39; =&amp;gt; &#39;utf8&#39;,
    &#39;attributes&#39; =&amp;gt; [
        PDO::ATTR_PERSISTENT =&amp;gt; true,
        PDO::MYSQL_ATTR_INIT_COMMAND =&amp;gt; &#39;SET sql_mode=&amp;quot;STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION&amp;quot;&#39;
    ],
];
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;решение-3-использование-агрегирующих-функций&#34;&gt;Решение 3 - использование агрегирующих функций&lt;/h2&gt;

&lt;p&gt;Если ваше приложение точно нуждается в получении поля user_id для какой-то корректной причины,
или слишком сложно менять исходный код (например, для поддержки обратной совместимости с внешними приложениями),
вы можете положиться на агрегирующие функции, чтобы избежать изменения SQL-режима.
Тогда для всех новых запросов проверка уже будет выполняться.&lt;/p&gt;

&lt;p&gt;Например мы можем использовать агрегирующие функции MAX(), MIN() или даже GROUP_CONCAT().&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-SQL&#34;&gt;mysql&amp;gt; SET SESSION sql_mode=&#39;ONLY_FULL_GROUP_BY&#39;;

mysql&amp;gt; SELECT page_url, MAX(user_id), COUNT(*) AS visits FROM web_log GROUP BY page_url ORDER BY COUNT(*) DESC;
+-------------------+--------------+--------+
| page_url          | MAX(user_id) | visits |
+-------------------+--------------+--------+
| /index.html       |            3 |      3 |
| /news.php         |            2 |      2 |
| /store_offers.php |            3 |      2 |
| /faq.html         |            1 |      1 |
+-------------------+--------------+--------+

mysql&amp;gt; SELECT page_url, GROUP_CONCAT(user_id), COUNT(*) AS visits FROM web_log GROUP BY page_url ORDER BY COUNT(*) DESC;
+-------------------+-----------------------+--------+
| page_url          | GROUP_CONCAT(user_id) | visits |
+-------------------+-----------------------+--------+
| /index.html       |                 1,2,3 |      3 |
| /news.php         |                   1,2 |      2 |
| /store_offers.php |                   3,2 |      2 |
| /faq.html         |                     1 |      1 |
+-------------------+-----------------------+--------+
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;MySQL даже предоставляет специальную функцию для решения этой проблемы: ANY_VALUE().&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-SQL&#34;&gt;mysql&amp;gt; SELECT page_url, ANY_VALUE(user_id), COUNT(*) AS visits FROM web_log GROUP BY page_url ORDER BY COUNT(*) DESC;
+-------------------+--------------------+--------+
| page_url          | ANY_VALUE(user_id) | visits |
+-------------------+--------------------+--------+
| /index.html       |                  1 |      3 |
| /news.php         |                  1 |      2 |
| /store_offers.php |                  3 |      2 |
| /faq.html         |                  1 |      1 |
+-------------------+--------------------+--------+
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;заключение&#34;&gt;Заключение&lt;/h2&gt;

&lt;p&gt;Лично я предпочитаю решение номер 1, так как оно заставляет вас писать запросы по стандарту SQL-92.
Следование стандартам часто считается лучшей практикой. Также хочу заметить, что это ловит часть ошибок,
аналогично статическому анализу кода.&lt;/p&gt;

&lt;p&gt;Решение 2 подходит, если вы не можете поменять код приложения или переписывание всех запросов
действительно очень сложное. Отличное решение исправить проблему за несколько секунд, хотя я настоятельно рекомендую иметь план по переписыванию запросов, которые соответствуют стандарту SQL-92.&lt;/p&gt;

&lt;p&gt;Больше деталей: &lt;a href=&#34;https://dev.mysql.com/doc/refman/5.7/en/group-by-handling.html&#34; target=&#34;_blank&#34;&gt;https://dev.mysql.com/doc/refman/5.7/en/group-by-handling.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;По мотивам
&lt;a href=&#34;https://www.percona.com/blog/2019/05/13/solve-query-failures-regarding-only_full_group_by-sql-mode/&#34; target=&#34;_blank&#34;&gt;https://www.percona.com/blog/2019/05/13/solve-query-failures-regarding-only_full_group_by-sql-mode/&lt;/a&gt;&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Cron в распределённой системе</title>
      <link>https://vitalyzhakov.github.io/post/cron-requirements/</link>
      <pubDate>Fri, 28 Aug 2020 00:00:00 +0000</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/cron-requirements/</guid>
      <description>

&lt;p&gt;Cron-задания часто являются одной из составляющих долгоживущего сервиса.&lt;/p&gt;

&lt;p&gt;Могут применяться как сборщики мусора.
Или как инициаторы заданий для воркеров.&lt;/p&gt;

&lt;h2 id=&#34;проблематика&#34;&gt;Проблематика&lt;/h2&gt;

&lt;p&gt;В большой распределённой системе cron-задания могут быть не рассчитаны на параллельную работу.
Например, не реализовывать протокол &lt;a href=&#34;https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_%D0%9F%D0%B0%D0%BA%D1%81%D0%BE%D1%81&#34; target=&#34;_blank&#34;&gt;Paxos&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Поэтому требуется реализовать блокировку от параллельного выполнения.&lt;/p&gt;

&lt;p&gt;Но начнём мы с часто совершаемой ошибки при полном цикле разработки и эксплуатации в разных отделах&lt;/p&gt;

&lt;h2 id=&#34;cron-находится-в-отличном-от-кода-репо-настраивается-вручную-по-заявке&#34;&gt;cron находится в отличном от кода репо / настраивается вручную по заявке&lt;/h2&gt;

&lt;p&gt;Предположу, что есть варианты, когда срок горит, а разбираться в CI/DevOps практиках лень.&lt;/p&gt;

&lt;p&gt;Тогда долгосрочной эксплуатации продукта отдаётся меньший приоритет, чем быстрому запуску.&lt;/p&gt;

&lt;p&gt;Как следствие - cron настраивается инженерами экплуатации в системе, к которой программистам доступа нет.&lt;/p&gt;

&lt;p&gt;Для грамотной разработки и поддержки важно понимать, как работает проект сейчас (в общем случае в конкретный момент времени).&lt;/p&gt;

&lt;p&gt;А так как cron - часть проекта, его работа должна быть понятной для всех (разработчиков, эксплуатации и т.д.).&lt;/p&gt;

&lt;p&gt;Поэтому вывод&lt;/p&gt;

&lt;h2 id=&#34;cron-должен-быть-реализован-в-проекте&#34;&gt;Cron должен быть реализован в проекте&lt;/h2&gt;

&lt;p&gt;Основные агурменты за:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;конфигурация на виду у всех членов команды, а не записана в блокноте у уволенного сотрудника;&lt;/li&gt;
&lt;li&gt;имеется возможность протестировать и внести изменения вместе с изменениями проекта;&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&#34;реализация&#34;&gt;Реализация&lt;/h2&gt;

&lt;p&gt;Обычно вызов cron операций бывает:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;асинхронным вызовом через сеть (веб-сервер или другой сигнал для запуска команды);&lt;/li&gt;
&lt;/ol&gt;

&lt;ul&gt;
&lt;li&gt;этот путь не даёт контроля над результатом выполнения cron-операции;&lt;/li&gt;
&lt;li&gt;возможен, если это постановка задания в очередь, а не выполнение самого задания.&lt;/li&gt;
&lt;li&gt;можно воспользоваться готовым образом &lt;a href=&#34;https://hub.docker.com/r/renskiy/cron/&#34; target=&#34;_blank&#34;&gt;https://hub.docker.com/r/renskiy/cron/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;ol&gt;
&lt;li&gt;вызовом операции в самом приложении&lt;/li&gt;
&lt;/ol&gt;

&lt;ul&gt;
&lt;li&gt;контроль исполнения;&lt;/li&gt;
&lt;li&gt;контроль ресурсов;&lt;/li&gt;
&lt;li&gt;получаем точный код и трассировку в случае ошибки.&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&#34;ограничения&#34;&gt;Ограничения&lt;/h2&gt;

&lt;p&gt;В распределённой системе нужно котролировать параллельный запуск, если возможны ошибки при параллельном выполнении двух cron-заданий.&lt;/p&gt;

&lt;h3 id=&#34;блокировка-от-параллельного-выполнения&#34;&gt;Блокировка от параллельного выполнения&lt;/h3&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;#!/bin/bash
PROCNUM=`ps xa | grep -v grep | grep -c &amp;quot;/srv/www/data/cron.php&amp;quot;`
# если процесс уже есть - выходим
if [ $PROCNUM -gt 0 ]; then exit; fi

/usr/local/bin/php /srv/www/data/cron.php
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;обработка-ошибок&#34;&gt;Обработка ошибок&lt;/h2&gt;

&lt;p&gt;Сообщения, которые затем должны быть видны в системе логирования, стоит записать в лог контейнера.
Система логирования автоматически их обработает и отдаст в удобном для клиента виде.&lt;/p&gt;

&lt;p&gt;Соответствует методике &lt;a href=&#34;https://12factor.net/ru/logs&#34; target=&#34;_blank&#34;&gt;12 факторов&lt;/a&gt;&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Ошибка с пространственным полем point при миграции из mysql 5.1 до mysql 8</title>
      <link>https://vitalyzhakov.github.io/post/migration-from-mysql-51-to-mysql-8-geometry-field/</link>
      <pubDate>Wed, 05 Aug 2020 00:10:06 +0500</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/migration-from-mysql-51-to-mysql-8-geometry-field/</guid>
      <description>

&lt;h2 id=&#34;постановка-задачи&#34;&gt;Постановка задачи&lt;/h2&gt;

&lt;p&gt;Был сервис на mysql 5.1. Нужно мигрировать на актуальную 8ю версию.&lt;/p&gt;

&lt;p&gt;Заход с помощью mysql workbench не увенчался успехом, так как 5.1 уже давно не поддерживают.&lt;/p&gt;

&lt;p&gt;mysqldump справился с задачей снять дамп, но при выполнении его на целевом сервере появились ошибки:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;Cannot get geometry object from data you send to the GEOMETRY field
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;диагностика&#34;&gt;Диагностика&lt;/h2&gt;

&lt;p&gt;Беглый поиск подводит к использованию mysqldump с ключом &lt;code&gt;--hex-blob&lt;/code&gt;, но к результату это не приводит.
Ошибка сохраняется.&lt;/p&gt;

&lt;p&gt;Экспорт дампа с ключами &lt;code&gt;--hex-blob --extended-insert=FALSE&lt;/code&gt; и последующий импорт даёт конкретную строку, в которой ошибка.
Просмотр дампа позволяет понять, что вместо геометрических данных mysqldump выгружает в пустых значениях &lt;code&gt;binary &#39;&#39;&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;Импорт в mysql 8 версии преобразовать это поле в геометрию точки не может.&lt;/p&gt;

&lt;p&gt;Но такое поведение замечено только при пустом исходном значении. При заполненном импортируется корректно.&lt;/p&gt;

&lt;h2 id=&#34;решение&#34;&gt;Решение&lt;/h2&gt;

&lt;p&gt;Замена в файле дампа  &lt;code&gt;,binary &#39;&#39;,&lt;/code&gt; -&amp;gt; &lt;code&gt;,NULL,&lt;/code&gt; (например, с помощью массовой замены в &lt;code&gt;mcedit&lt;/code&gt;).&lt;/p&gt;

&lt;p&gt;В моём случае также пришлось снять обязательность на поле &lt;code&gt;point&lt;/code&gt;.&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>VSCode for php</title>
      <link>https://vitalyzhakov.github.io/post/vscode-php/</link>
      <pubDate>Tue, 19 May 2020 00:10:06 +0500</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/vscode-php/</guid>
      <description>

&lt;h2 id=&#34;работа-с-git-по-ssh&#34;&gt;Работа с git по SSH&lt;/h2&gt;

&lt;p&gt;Приватный ключ может быть защищён паролем, поэтому на Linux-based системах
перед началом работы для использования такого ключа нужно воспользоваться командой&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;ssh-add ключ
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;рекомендуемые-расширения&#34;&gt;Рекомендуемые расширения&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://marketplace.visualstudio.com/items?itemName=bmewburn.vscode-intelephense-client&#34; target=&#34;_blank&#34;&gt;vscode-intelephense-client&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker&#34; target=&#34;_blank&#34;&gt;code-spell-checker&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker-russian&#34; target=&#34;_blank&#34;&gt;code-spell-checker-russian&lt;/a&gt; После установки в readme spell checker russian написано, как добавить русский язык в проверку.&lt;/li&gt;
&lt;li&gt;GitLens&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack&#34; target=&#34;_blank&#34;&gt;Remote development containers&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</description>
    </item>
    
    <item>
      <title>Вычисление размеров изделия с помощью степеней свободы FreeCAD</title>
      <link>https://vitalyzhakov.github.io/post/freecad-degree-of-freedom/</link>
      <pubDate>Wed, 06 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/freecad-degree-of-freedom/</guid>
      <description>&lt;p&gt;Недавно я столкнулся с простой бытовой потребностью - повесить полочки на стену.
Так как стена плоская, полка должна опираться на уголки.&lt;/p&gt;

&lt;p&gt;Вроде таких
&lt;img src=&#34;https://yunimag.ru/images/big/206362_1.jpg&#34; alt=&#34;Уголок&#34; /&gt;&lt;/p&gt;

&lt;p&gt;В магазине самые большие уголки длиной до 150 мм.&lt;/p&gt;

&lt;p&gt;Ширина полки меня бы устроила ~300 мм, длина ~2 метра.
Магазинный уголок, очевидно, не выдержит такую нагрузку.&lt;/p&gt;

&lt;p&gt;В режиме самоизоляции ходить по магазинам не очень удобно,
поэтому я решил немного прокачаться во FreeCAD и изготовить уголок самостоятельно.&lt;/p&gt;

&lt;p&gt;Для увеличения прочности изделия уголок будет состоять из трёх частей:&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/freecad-degree-of-freedom/chernovik.png&#34; alt=&#34;Черновик будущего уголка&#34; title=&#34;Черновик&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Самое интересное - как посчитать, конкретные размеры, чтобы было красиво (но не подгонять их руками).&lt;/p&gt;

&lt;p&gt;Благодаря степеням свободы, мы можем задать только углы и равенство отрезков.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/freecad-degree-of-freedom/ugolok-no-freedom.png&#34; alt=&#34;Черновик будущего уголка&#34; title=&#34;Черновик&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Нам останется задать в терминах длины только 2 параметра:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;ширину бруска;&lt;/li&gt;
&lt;li&gt;высоту бруска, прилегающего к стене.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Всё остально FreeCAD посчитает за нас!&lt;/p&gt;

&lt;p&gt;Например, при высоте вертикального бруска 350мм, горизонтальный будет длиной 270 мм.
Узнаём снова применением ограничения расстояния между точками либо длины по горизонтали/вертикали.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/freecad-degree-of-freedom/horizontal-length-270.png&#34; alt=&#34;Черновик будущего уголка&#34; title=&#34;Черновик&#34; /&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href=&#34;https://vitalyzhakov.github.io/images/freecad-degree-of-freedom/ugolok-2d.FCStd&#34;&gt;Скачать исходник&lt;/a&gt;&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Graylog</title>
      <link>https://vitalyzhakov.github.io/post/graylog/</link>
      <pubDate>Fri, 24 Apr 2020 00:10:06 +0500</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/graylog/</guid>
      <description>

&lt;p&gt;В нашей жизни происходят разные события.
Совсем разные.
Например, люди заболевают коронавирусом.&lt;/p&gt;

&lt;p&gt;Для различных прикладных задач важно знать,
когда, на какой территории сколько человек заболело,
чтобы своевременно действовать.&lt;/p&gt;

&lt;p&gt;Как это происходит с точки зрения процесса:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;больного записывают в журнал с указанием важных атрибутов (дата, время, диагноз, место проживания);&lt;/li&gt;
&lt;li&gt;данные передаются на центральный узел сбора;&lt;/li&gt;
&lt;li&gt;специалисты анализируют данные, делают выводы.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Наши сервисы также могут отсылать события в централизованную систему (graylog).
Пример события:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;наш веб-сервер обслуживает пользователя, отправляет время и длительность ответа;&lt;/li&gt;
&lt;li&gt;очередь обновлений: записывается категория задания, город и длительность.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;После того, как мы записали данные, в удобном интерфейсе можем делать анализ событий.&lt;/p&gt;

&lt;p&gt;Примеры:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;узнать нагрузку на сервис по минутам;&lt;/li&gt;
&lt;li&gt;узнать IP клиентов;&lt;/li&gt;
&lt;li&gt;посмотреть среднее или перцентиль времени ответа;&lt;/li&gt;
&lt;li&gt;узнать количество 500х.&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&#34;вопросы-и-ответы&#34;&gt;Вопросы и ответы&lt;/h2&gt;

&lt;h3 id=&#34;чем-graylog-отличается-от-google-analytics&#34;&gt;Чем graylog отличается от google analytics&lt;/h3&gt;

&lt;p&gt;Если посмотреть сверху, ничем. Обе системы анализируют поток событий.
Но google analytcs - специализированный инструмент, предназначенный для сбора метрик с браузера.
Для его работы требуется доступ в интернет.&lt;/p&gt;

&lt;p&gt;Благодаря тому, что инструмент специализированный,
в нём хорошо решается конкретная задача по сбору и обработке событий в браузере.&lt;/p&gt;

&lt;p&gt;В противоположность goolge analytics, graylog - инструмент универсальный.
Но эта гибкость лишает нас большого количества стандартных отчётов.&lt;/p&gt;

&lt;p&gt;С другой стороны при разработке сервиса лишь малая часть покрывается событиями из клиентского браузера.&lt;/p&gt;

&lt;p&gt;Поэтому стоит выбрать инструмент под задачу.&lt;/p&gt;

&lt;h3 id=&#34;другие-инструменты-например-elk-или-splunk&#34;&gt;Другие инструменты, например, ELK или splunk&lt;/h3&gt;

&lt;p&gt;Принцип работы у всех продуктов один и тот же, я же призываю вас поддержать open-source продукт.
Вы можете внести &lt;a href=&#34;https://github.com/Graylog2/graylog2-server&#34; target=&#34;_blank&#34;&gt;свой вклад&lt;/a&gt;
путём отправки ошибок в баг-трекер или оформлять документацию,
писать код или отвечать на вопросы пользователей.&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>Репликация MySQL-серверов с помощью Docker</title>
      <link>https://vitalyzhakov.github.io/post/mysql-replication-docker/</link>
      <pubDate>Fri, 10 Apr 2020 00:10:06 +0500</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/mysql-replication-docker/</guid>
      <description>

&lt;p&gt;До выхода приложения в бой, нужно смоделировать его поведение
&lt;a href=&#34;https://vitalyzhakov.github.io/post/sandbox-for-web-developers/&#34;&gt;в тестовой среде&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Технология Docker Swarm позволяет легко масштабировать приложение горизонтально.
Но часто приложению приходится обращаться к серверу баз данных, задача масшабировать который гораздо труднее.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/several-upstream-one-db.svg&#34; alt=&#34;Много приложений - одна база&#34; title=&#34;Много приложений - одна база&#34; /&gt;&lt;/p&gt;

&lt;p&gt;В нашем случае количество запросов на чтение информации гораздо меньше количества изменений
(есть подозрение, что так на большинстве веб-проектов).
Логичный способ увеличения такого бутылочного горлышка -
увеличить количество баз на чтение и настроить приложение таким образом,
чтобы большее количество запросов на чтение
отправлялось на SLAVE-сервера.&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/several-upstream-several-dbs.svg&#34; alt=&#34;Много приложений - одна база&#34; title=&#34;Много приложений - много баз&#34; /&gt;&lt;/p&gt;

&lt;h2 id=&#34;предварительная-установка&#34;&gt;Предварительная установка&lt;/h2&gt;

&lt;p&gt;Установить docker, docker-compose на вашу операционную систему.&lt;/p&gt;

&lt;p&gt;Текст далее протестирован на&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Ubuntu 18.04&lt;/li&gt;
&lt;li&gt;docker 18.09&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://docs.docker.com/compose/install/&#34; target=&#34;_blank&#34;&gt;docker-compose&lt;/a&gt; 1.25.4&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&#34;проект&#34;&gt;Проект&lt;/h2&gt;

&lt;p&gt;Создадим папку, где будет располагаться конфигурация серверов&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;mkdir db-replication
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;и перейдём в неё&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;cd db-replication
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Дальнейшие действия будут производиться относительно папки с проектом.&lt;/p&gt;

&lt;h2 id=&#34;настройка-репликации&#34;&gt;Настройка репликации&lt;/h2&gt;

&lt;p&gt;Создадим папку для хранения конфигураций серверов mysql&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;mkdir -p build_env/mysql
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&#34;изменение-в-my-cnf-для-каждого-сервера&#34;&gt;Изменение в my.cnf для каждого сервера&lt;/h3&gt;

&lt;p&gt;Каждый сервер должен иметь свой номер.
Master-сервер &lt;code&gt;server-id=1&lt;/code&gt;.
Slave-сервер &lt;code&gt;server-id&amp;gt;1&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;Конфигурационный файл находится по адресу
&lt;code&gt;/etc/mysql/conf.d/my.cnf&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;Создадим файл конфигурации master-сервера&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;nano build_env/mysql/master.cnf
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;с содержимым&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;[mysqld]
server-id=1
binlog_format=ROW
log-bin
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Конфигурация slave1&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;nano build_env/mysql/slave1.cnf
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;[mysqld]
server-id=2
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Конфигурация slave2&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;nano build_env/mysql/slave2.cnf
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;[mysqld]
server-id=3
&lt;/code&gt;&lt;/pre&gt;

&lt;h3 id=&#34;изменения-при-старте-сервера&#34;&gt;Изменения при старте сервера&lt;/h3&gt;

&lt;p&gt;На master-сервере нужно выдать права пользователю для чтения файла лога&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;nano build_env/mysql/master.sql
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code class=&#34;language-sql&#34;&gt;CREATE USER repl@&#39;%&#39; IDENTIFIED WITH mysql_native_password BY &#39;slavepass&#39;;
GRANT REPLICATION SLAVE ON *.* TO repl@&#39;%&#39;;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;На slave-сервере нужно указать координаты для подключения к master&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;nano build_env/mysql/slave.sql
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code class=&#34;language-sql&#34;&gt;CHANGE MASTER TO MASTER_HOST=&#39;db-master&#39;, MASTER_USER=&#39;repl&#39;, MASTER_PASSWORD=&#39;slavepass&#39;;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Создадим файл для docker-compose&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;nano docker-compose.yml
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;с содержимым&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-yml&#34;&gt;version: &#39;3.7&#39;

services:
    mysql:
        image: &#39;percona:8.0&#39;
        container_name: db-master
        volumes:
            - ./build_env/mysql/master.cnf:/etc/my.cnf.d/repl.cnf
            - ./build_env/mysql/master.sql:/docker-entrypoint-initdb.d/start.sql
        environment:
            MYSQL_ROOT_PASSWORD: &amp;quot;secret&amp;quot;

    mysqlread1:
        image: &#39;percona:8.0&#39;
        container_name: db-slave1
        volumes:
            - ./build_env/mysql/slave1.cnf:/etc/my.cnf.d/repl.cnf
            - ./build_env/mysql/slave.sql:/docker-entrypoint-initdb.d/start.sql
        depends_on:
            - mysql
        environment:
            MYSQL_ROOT_PASSWORD: &amp;quot;secret&amp;quot;

    mysqlread2:
        image: &#39;percona:8.0&#39;
        container_name: db-slave2
        volumes:
            - ./build_env/mysql/slave2.cnf:/etc/my.cnf.d/repl.cnf
            - ./build_env/mysql/slave.sql:/docker-entrypoint-initdb.d/start.sql
        depends_on:
            - mysql
        environment:
            MYSQL_ROOT_PASSWORD: &amp;quot;secret&amp;quot;
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;запуск&#34;&gt;Запуск&lt;/h2&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;docker-compose rm -vf &amp;amp;&amp;amp; docker-compose up
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;проверка&#34;&gt;Проверка&lt;/h2&gt;

&lt;p&gt;Открываем ещё 1 терминал, заходим в master-сервер&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;docker exec -it db-master mysql -uroot -psecret
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;И ещё 1 терминал, заходим в любой slave&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;docker exec -it db-slave1 mysql -uroot -psecret
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;На master выполняем&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-sql&#34;&gt;show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Создадим на master базу данных &lt;code&gt;test&lt;/code&gt;&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-sql&#34;&gt;create database test;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;В подключении для slave проверяем, появилась ли созданная на master база данных:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-sql&#34;&gt;show databases;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;В выводе должна появиться база данных &lt;code&gt;test&lt;/code&gt;.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-sql&#34;&gt;+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test               |
+--------------------+
&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&#34;диагностика&#34;&gt;Диагностика&lt;/h2&gt;

&lt;p&gt;Для диагностики нужно иметь возможность подключения к консоли mysql.
Подключаемся к master-серверу:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;docker exec -it db-master mysql -uroot -psecret
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Смотрим статус&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;mysql&amp;gt; show master status;
+-------------------+----------+--------------+------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| mysqld-bin.000004 |   119471 |              |                  |
+-------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;В процессах master-сервера мы можем видеть подключения со SLAVE-контейнеров, либо ошибки&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;mysql&amp;gt; SHOW PROCESSLIST;  
+----+-----------------+------------------+------+-------------+------+---------------------------------------------------------------+------------------+-----------+---------------+
| Id | User            | Host             | db   | Command     | Time | State                                                         | Info             | Rows_sent | Rows_examined |
+----+-----------------+------------------+------+-------------+------+---------------------------------------------------------------+------------------+-----------+---------------+
|  4 | event_scheduler | localhost        | NULL | Daemon      |  234 | Waiting on empty queue                                        | NULL             |         0 |             0 |
|  8 | repl            | 172.18.0.4:57040 | NULL | Binlog Dump |  230 | Master has sent all binlog to slave; waiting for more updates | NULL             |         0 |             0 |
|  9 | repl            | 172.18.0.3:51798 | NULL | Binlog Dump |  228 | Master has sent all binlog to slave; waiting for more updates | NULL             |         0 |             0 |
| 10 | root            | localhost        | NULL | Query       |    0 | starting                                                      | SHOW PROCESSLIST |         0 |             0 |
+----+-----------------+------------------+------+-------------+------+---------------------------------------------------------------+------------------+-----------+---------------+
4 rows in set (0.00 sec)
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Для slave-сервера&lt;/p&gt;

&lt;pre&gt;&lt;code class=&#34;language-bash&#34;&gt;docker exec -it db-slave1 mysql -uroot -psecret
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code&gt;mysql&amp;gt; SHOW SLAVE STATUS;
+----------------------------------+-------------+-------------+-------------+---------------+-------------------------+---------------------+-------------------------------+---------------+-------------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+-------------------------------+---------------+---------------+----------------+----------------+-----------------------------+------------------+--------------------------------------+-------------------------+-----------+---------------------+--------------------------------------------------------+--------------------+-------------+-------------------------+--------------------------+----------------+--------------------+--------------------+-------------------+---------------+----------------------+--------------+--------------------+------------------------+-----------------------+-------------------+
| Slave_IO_State                   | Master_Host | Master_User | Master_Port | Connect_Retry | Master_Log_File         | Read_Master_Log_Pos | Relay_Log_File                | Relay_Log_Pos | Relay_Master_Log_File   | Slave_IO_Running | Slave_SQL_Running | Replicate_Do_DB | Replicate_Ignore_DB | Replicate_Do_Table | Replicate_Ignore_Table | Replicate_Wild_Do_Table | Replicate_Wild_Ignore_Table | Last_Errno | Last_Error | Skip_Counter | Exec_Master_Log_Pos | Relay_Log_Space | Until_Condition | Until_Log_File | Until_Log_Pos | Master_SSL_Allowed | Master_SSL_CA_File | Master_SSL_CA_Path | Master_SSL_Cert | Master_SSL_Cipher | Master_SSL_Key | Seconds_Behind_Master | Master_SSL_Verify_Server_Cert | Last_IO_Errno | Last_IO_Error | Last_SQL_Errno | Last_SQL_Error | Replicate_Ignore_Server_Ids | Master_Server_Id | Master_UUID                          | Master_Info_File        | SQL_Delay | SQL_Remaining_Delay | Slave_SQL_Running_State                                | Master_Retry_Count | Master_Bind | Last_IO_Error_Timestamp | Last_SQL_Error_Timestamp | Master_SSL_Crl | Master_SSL_Crlpath | Retrieved_Gtid_Set | Executed_Gtid_Set | Auto_Position | Replicate_Rewrite_DB | Channel_Name | Master_TLS_Version | Master_public_key_path | Get_master_public_key | Network_Namespace |
+----------------------------------+-------------+-------------+-------------+---------------+-------------------------+---------------------+-------------------------------+---------------+-------------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+-------------------------------+---------------+---------------+----------------+----------------+-----------------------------+------------------+--------------------------------------+-------------------------+-----------+---------------------+--------------------------------------------------------+--------------------+-------------+-------------------------+--------------------------+----------------+--------------------+--------------------+-------------------+---------------+----------------------+--------------+--------------------+------------------------+-----------------------+-------------------+
| Waiting for master to send event | db-master   | repl        |        3306 |            60 | 07a9adad7189-bin.000003 |                 155 | 0c53f622dac3-relay-bin.000005 |           383 | 07a9adad7189-bin.000003 | Yes              | Yes               |                 |                     |                    |                        |                         |                             |          0 |            |            0 |                 155 |         2955798 | None            |                |             0 | No                 |                    |                    |                 |                   |                |                     0 | No                            |             0 |               |              0 |                |                             |                1 | b9bb3878-7c11-11ea-9d4d-0242ac120002 | mysql.slave_master_info |         0 |                NULL | Slave has read all relay log; waiting for more updates |              86400 |             |                         |                          |                |                    |                    |                   |             0 |                      |              |                    |                        |                     0 |                   |
+----------------------------------+-------------+-------------+-------------+---------------+-------------------------+---------------------+-------------------------------+---------------+-------------------------+------------------+-------------------+-----------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+-------------------------------+---------------+---------------+----------------+----------------+-----------------------------+------------------+--------------------------------------+-------------------------+-----------+---------------------+--------------------------------------------------------+--------------------+-------------+-------------------------+--------------------------+----------------+--------------------+--------------------+-------------------+---------------+----------------------+--------------+--------------------+------------------------+-----------------------+-------------------+
1 row in set (0.00 sec)
&lt;/code&gt;&lt;/pre&gt;
</description>
    </item>
    
    <item>
      <title>Оптимизация скорости загрузки</title>
      <link>https://vitalyzhakov.github.io/post/page-load-time-optimizing/</link>
      <pubDate>Mon, 03 Feb 2020 00:00:00 +0000</pubDate>
      
      <guid>https://vitalyzhakov.github.io/post/page-load-time-optimizing/</guid>
      <description>

&lt;h2 id=&#34;шаг-1-постановка-цели&#34;&gt;Шаг 1. Постановка цели&lt;/h2&gt;

&lt;p&gt;Основное на этом шаге - определиться, зачем вам оптимизировать
скорость загрузки.
К примеру, у вас сайт-визитка, продаёте вы бани под ключ.
Продажи происходят в той же бане, за столом или по телефону.&lt;/p&gt;

&lt;p&gt;Вполне возможно, что очередная секунда времени загрузки не влияет на продажи и
вложенные затраты не окупятся.&lt;/p&gt;

&lt;p&gt;Стоит сфокусироваться на тех сайтах или страницах, которые влияют на ваши целевые показатели.&lt;/p&gt;

&lt;h2 id=&#34;шаг-2-сбор-статистики-и-выбор-узкого-места-для-оптимизации&#34;&gt;Шаг 2. Сбор статистики и выбор узкого места для оптимизации&lt;/h2&gt;

&lt;p&gt;Во-первых, обратимся к событиям, вызываевым на разных
&lt;a href=&#34;https://www.w3.org/TR/navigation-timing/&#34; target=&#34;_blank&#34;&gt;стадиях загрузки страницы&lt;/a&gt;:&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://www.w3.org/TR/navigation-timing/timing-overview.png&#34; alt=&#34;Диаграмма времени загрузки&#34; title=&#34;Диаграмма времени загрузки&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Современные браузеры поддерживают &lt;a href=&#34;https://caniuse.com/#feat=nav-timing&#34; target=&#34;_blank&#34;&gt;Navigation Timing API&lt;/a&gt;,
который предоставляет информацию, когда произошло конкретное событие в течение загрузки страницы.&lt;/p&gt;

&lt;p&gt;Метрики можно смотреть на локальном компьютере либо собирать их с клиента на сервер и затем делать выводы.
У обоих подходов есть плюсы и минусы, давайте их рассмотрим.&lt;/p&gt;

&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Фактор сравнения&lt;/th&gt;
&lt;th&gt;Отслеживание на локальном компьютере&lt;/th&gt;
&lt;th&gt;Развёртывание сервера и выводы в дальшейнем&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;

&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Порог входа&lt;/td&gt;
&lt;td&gt;Не требует установки дополнительного ПО&lt;/td&gt;
&lt;td&gt;Требует сервера приёма метрик и их анализа&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;Реальность значений&lt;/td&gt;
&lt;td&gt;Только модель, нет конкретных значений&lt;/td&gt;
&lt;td&gt;Данные собраны с реальных пользователей&lt;/td&gt;
&lt;/tr&gt;

&lt;tr&gt;
&lt;td&gt;Точность результатов&lt;/td&gt;
&lt;td&gt;Результаты меняются от измерения к измерению&lt;/td&gt;
&lt;td&gt;Чем больше посещений страниц, тем точнее результат&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;

&lt;p&gt;Возможно применение сервисов, которые позволят собрать реальные данные,
не тратя время на равёртывание сервиса сбора метрик.
Например, &lt;code&gt;google analytics&lt;/code&gt; и её отчёт по скорости.&lt;/p&gt;

&lt;p&gt;Субьективно все инструменты делятся на 4 типа:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;встроенные в браузер (debug панель FireFox, Chrome);&lt;/li&gt;
&lt;li&gt;одноразовые сервисы - одно измерение, не отражающее действительность в силу их &lt;a href=&#34;https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B0%D1%82%D0%B8%D1%81%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D0%B7%D0%BD%D0%B0%D1%87%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D1%8C&#34; target=&#34;_blank&#34;&gt;статической незначимости&lt;/a&gt;;&lt;/li&gt;
&lt;li&gt;скрипты сбора статистики, встроенные в счётики (Яндекс Метрика, Google Analytics);&lt;/li&gt;
&lt;li&gt;управляемый сбор статистики путём имитации клиента &lt;a href=&#34;https://vitalyzhakov.github.io/post/sitespeed/&#34;&gt;sitespeed.io&lt;/a&gt;.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Например, &lt;code&gt;google analytics&lt;/code&gt; по умолчанию собираются метрики по времени загрузки с 1% пользователей.&lt;/p&gt;

&lt;p&gt;При большом количестве просмотров страниц метрики начинают показывать стабильные результаты.&lt;/p&gt;

&lt;p&gt;Но как их улучшить?&lt;/p&gt;

&lt;h2 id=&#34;шаг-3-выявление-узкого-места&#34;&gt;Шаг 3. Выявление узкого места&lt;/h2&gt;

&lt;p&gt;В оптимизации важно применить усилие в нужное место.&lt;/p&gt;

&lt;h3 id=&#34;вариант-за-дёшево&#34;&gt;Вариант &amp;ldquo;за дёшево&amp;rdquo;&lt;/h3&gt;

&lt;p&gt;Заходим в Chromium, запускаем вкладку Audits&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/page-load-time-optimizing/chromium-new-audit.png&#34; alt=&#34;Запуск Audit в Chromium&#34; title=&#34;Запуск Audit в Chromium&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Через несколько секунд получаем результат&lt;/p&gt;

&lt;p&gt;&lt;img src=&#34;https://vitalyzhakov.github.io/images/page-load-time-optimizing/chromium-audit-result.png&#34; alt=&#34;Результат Audit в Chromium&#34; title=&#34;Результат Audit в Chromium&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Lighthouse, встроенный в инструменты разработчика Chromium,
отсортировал для нас факторы оптимизации в порядке приносимых эффектов.&lt;/p&gt;

&lt;p&gt;В данном примере рекомендуют минимизировать работу в главном потоке путём минимизации выполнения JS.&lt;/p&gt;

&lt;h3 id=&#34;вариант-по-статистическим-данным&#34;&gt;Вариант &amp;ldquo;по статистическим данным&amp;rdquo;&lt;/h3&gt;

&lt;p&gt;В &lt;code&gt;google analytics&lt;/code&gt; находим отчёт по скорости загрузки страниц.&lt;/p&gt;

&lt;p&gt;Для наглядности на основе данных я построил диаграмму
&lt;img src=&#34;https://vitalyzhakov.github.io/images/page-load-time-optimizing/timings-from-ga.png&#34; alt=&#34;Page timings&#34; title=&#34;Page timings&#34; /&gt;&lt;/p&gt;

&lt;p&gt;Видно, что узкое место - время ответа сервера.
На втором месте - переадресация.&lt;/p&gt;

&lt;p&gt;В таком же порядке стоит начать оптимизировать. Сначала время ответа сервера, затем - уменьшение переадресаций.&lt;/p&gt;

&lt;h2 id=&#34;шаг-4-сама-оптимизация&#34;&gt;Шаг 4. Сама оптимизация&lt;/h2&gt;

&lt;p&gt;В зависимости от узкого места оптимизировать его ;)&lt;/p&gt;

&lt;p&gt;Общие рекомендации для бек-енда:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Cчитать данные заранее, клиенту в момент запроса отдавать сразу поготовленные данные;&lt;/li&gt;
&lt;li&gt;Быть гибким для клиента и выдавать только запрошенные поля / выдавать подготовленные данные, подходящие именно для конкретной страницы;&lt;/li&gt;
&lt;li&gt;Стремиться отдавать 90% ответов клиенту за 100ms;&lt;/li&gt;
&lt;li&gt;Исходя из требований времени ответа не допускать запросов при формировании ответов, находящихся на расстоянии больше чем 40-50ms.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Общие &lt;a href=&#34;https://developers.google.com/web/tools/chrome-devtools/rendering-tools&#34; target=&#34;_blank&#34;&gt;рекомендации для фронт-енда&lt;/a&gt;:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Не пишите JavaScript, который заставляет браузер пересчитывать макет страницы.&lt;/li&gt;
&lt;li&gt;Не усложняйте свой CSS. Используйте меньше CSS и делайте ваши CSS-селекторы простыми.&lt;/li&gt;
&lt;li&gt;Исключайте перерисовку где только возможно. Выбирайте CSS, которые не вызывают пересчёт макета страницы целиком.&lt;/li&gt;
&lt;li&gt;Отрисовка страницы может занять больше времени, чем любая другая активность при рендеринге. Следите за узкими местами отрисовки.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;a href=&#34;https://developers.google.com/web/tools/chrome-devtools/speed/get-started&#34; target=&#34;_blank&#34;&gt;Оптимизация блога кота Тони&lt;/a&gt;&lt;/p&gt;
</description>
    </item>
    
  </channel>
</rss>