Привет, Хабр! Я  исполнительный директор по разработке департамента ML и BD Газпромбанка. Сегодня хочу поговорить с вами о деплое.

По данным, приведенным в Google SRE book, до 70% проблем происходит вследствие изменений в уже работающих системах. По моим личным ощущениям, это близко к правде: если у вас хорошо спроектированное и написанное приложение и стабильная, отлаженная инфраструктура, именно деплой — узкое место (которое можно улучшить). Для минимизации рисков Google SRE BOOK рекомендует использовать постепенные выкаты, быстро и точно анализировать проблемы, а в случае необходимости легко откатываться обратно. 

Эта статья о деплое в Kubernetes, потому что это самая популярная инфраструктурная платформа, которая уже имеет множество возможностей для построения отказоустойчивых выкатов. А то, чего не хватает «из коробки», покрывается возможностями инструментов развитой экосистемы. 

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

Те, кто больше любит слушать, чем читать, могут посмотреть мой доклад про это на HighLoad++. Остальным — добро пожаловать под кат.

Этот материал представляет собой глубокое исследование всего, что связано с Redis. В частности — речь пойдёт о различных способах организации хранилищ Redis, о постоянном хранении данных, о форках процессов.

Однажды мне понадобилось внедрить метрики в сервисы своей команды. С самого начала я не понимал, что именно хочу получить: одно дело — прикрутить библиотеку и нарисовать графики, другое дело — показывать осмысленные данные.

Мне нужен был гайд, который сочетает эти две вещи: сначала «почему так принято», а затем — «как правильно делать». В результате такой гайд мне пришлось написать самому. Его цель — объяснить разработчикам с любым бэкграундом, что такое метрики, как правильно о них думать и осмысленно использовать. Сначала гайд жил во внутренней документации Точки, но я решил сделать его публичным — возможно, кому-то этот опыт будет полезен. Разбираться будем с Prometheus и Grafana. Если у вас другой стек — не страшно. Мы затронем и фундаментальные темы: например, перцентили, производные и кардинальность.

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

Сейчас мы живём в период, когда блокировки непредсказуемым образом усложняют нам жизнь. Одной из возможных угроз, которые стоит учесть, является блокировка протокола SSH (по причине того, что он позволяет организовывать туннели), и, хотя мы наверняка найдём способ достучаться до своих VPS, возможно стоит подстелить соломки и рассмотреть такой вариант, как SSH-клиент в браузере, что позволяет сделать программа Shellinabox.

Эта статья является продолжением моего «крестового похода» против ветряных мельниц убогих современных тенденций в разметке и оформлении веб-приложений (статья1, статья2). И, поверьте — солидная ее часть — это толерантная, такая, чтобы никоим образом не нарушить NDA, переработка реального доноса код-ревью кода важного боевого проекта для руководства одной из команд в которых мне приходилось участвовать. До этого момента я породил уже три достаточно злых, токсичных длиннопоста для сообщества, и, о чудо — ни один из них не умудрился скатился в минус (но последний был близок). И на этот раз — я готов! Ибо этот пост именно о тех технологиях и подходах к верстке, которые мне[, конечно же, на основе коммерческого опыта] кажутся весьма неудачными и неэффективными, неадекватными в очень многих ситуациях. Конечно, существуют команды, проекты, требования когда каждый из этих подходов может окажется вполне приемлемым и уместным. Но на деле, чаще всего, имхо, оказывается, что поборники данных методов — безальтернативно «подсаживаются на любимую иглу» и упорно не хотят знать и уметь, использовать ничего другого... Мне вообще кажется что мир вокруг нас сейчас это, утопия, практически целиком, максимально упрощенная тотальным засильем пролоббированного рептилоидами, мировой закулисой корпорациями тоталитарного глобального мейнстрима, и это одинаково касается всех сфер жизни, культуры, вот тут можно почитать мою философскую статью на тему применительно как раз к интерфейсам Куда подевались социальные сети? Пропаганда и реклама вместо общения... И даже наш любимый журнал о технической культуре, по сути, превратился в рекламную помойку, по большей части, унылое отражение глобального общественного тренда... Но, как известно — «главное попытаться», поэтому — поехали!

Рекомендуемый минимум

Ниже приведены основные элементы для любого веб-документа (веб-сайта/приложения):

meta charset — определяет кодировку веб-сайта, стандартом является utf-8.

meta name="viewport" — настройки viewport, связанные с мобильной отзывчивостью

width=device-width — физическая ширина устройства (отлично подходит для мобильных устройств!)

initial-scale=1 — начальный масштаб, 1 означает отсутствие масштабирования

Элементы

Допустимые элементы <head> включают meta, link, title, style, script, noscript и base.

Эти элементы предоставляют информацию о том, как документ должен восприниматься и отображаться веб-технологиями, например, браузерами, поисковыми системами, ботами и так далее.

Привет!

Меня зовут Михаил, я заместитель директора по ИТ в компании «Спортмастер». Я хочу поделиться историей о том, как мы справились с трудностями, возникшими во время пандемии.

В первые дни новых реалий привычный формат офлайн-торговли «Спортмастера» замер, и нагрузка на наш онлайн-канал, в первую очередь в части доставки на адрес клиенту, возросла в 10 раз. За несколько недель мы трансформировали гигантский по объему офлайн-бизнес в онлайн, адаптировали сервис под потребности наших клиентов.

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

Нет худа без добра! В очередной раз народная мудрость подтверждается, но только в этот раз с помощью осточертевшего коронавируса. Всех перевели на удалёнку, открыто много подписочного контента и, как следствие, в телекоме произошёл взрывной рост трафика. По разным оценкам, трафик в пользовательских сегментах уже вырос процентов на 80% и не думает останавливаться. Трафик попёр настолько сильно, что в нескольких странах Netflix, Youtube и прочие стриминговые сервисы сначала просили ограничить, а теперь им фактически запрещают передачу контента в HD качестве. Ибо пользователи настолько активно взялись за работу из дома, что места для развлечений в каналах у операторов просто не осталось.

А вот кто действительно сейчас не успевает подставлять мешки под поток хлынувших денег, так это провайдеры VPN-сервисов и всех, кто связан с их обслуживанием. Благо у одних своего VPN не было и проще купить готовый сервис, у других он был просто не рассчитан на такой поток пользователей и скончался под нагрузкой в первый же день. Словом, VPN — это сейчас самое популярное слово в телеком-мире. Вероятно, даже популярнее этой проклятой чумы.

И вот тут стоит задать себе вопрос — а в чём же сложность взять и организовать удобный VPN-сервис, а затем просто поддерживать его? Технология придумана далеко не вчера, все варианты давно известны, так почему же вокруг неё столько разговоров?

Но дабы не писать миллион первую статью про тонкости настройки OpenVPN, IPSec и прочих, давайте подойдём с другой стороны — а бывает так, что VPN делается быстро, удобно и бесплатно? Вот чтобы действительно десяток кликов — и работает как часы. И site-to-site, чтобы офисы связать, и site-to-point, чтобы удалёнщикам было быстро и удобно.

Спойлер — бывает.

Пруфы и рассуждения — под катом.

• базовая работа web сервера — обработка html;
• запуск php скриптов;
• корректная работа phpmyadmin для всех сайтов на сервере;
• запуск cgi и pl скриптов;
• использование кеширования и подбор оптимальных параметров для увеличения производительности.