DevOps и инфраструктура — страница 9

Друзья, хочу поделиться хорошей новостьюНедавно меня и Строительную экосистему «Звезда», как ответственного застройщика и работодателя, пригласили выступить на пленарном заседании XXIII Международной научно-практической конференции «Проблемы инженерного и социально-экономического образования в техническом вузе в условиях модернизации высшего образования». Да, название внушительное — но и сама встреча была действительно серьёзной!Я выступал с докладом на тему: «Профессия на стыке эпох: кем будет инженер через пять лет?»Главная мысль, которую я хотел донести: инженер будущего — это архитектор решений. Он проектирует не просто здания, а целые сценарии взаимодействия между людьми, технологиями, экологией и данными.Уже сегодня нейросети проектируют дома, рассчитывают нагрузки и оптимизируют логистику. Завтра это станет стандартом. И инженеру больше не придётся тратить время на рутину: расчёты, чертежи, документацию.О массовой замене рабочей силы пугают и публичные фронтмены Силиконовой долины. Маск уже сообщил, что развитие искусственного интеллекта и робототехники будет означать, что «вероятно, ни у кого из нас не будет работы». Гейтс тоже недавно рассказал, что люди скоро не понадобятся «для большинства вещей».Но даже в этом сценарии роль инженера не исчезает — она меняется. Инженер будущего — это визионер. Он будет формулировать задачи для ИИ, анализировать комплексные данные, находить нестандартные решения и определять вектор развития проектов.Спасибо Тюменскому индустриальному университету за приглашение, тёплый приём и возможность обсудить важные темы с настоящими профессионалами и единомышленниками 🙌Такие встречи вдохновляют и убеждают: мы движемся в правильном направлении.

6. Хостеры (AWS, Azure, Google Cloud)- Как и мобильные операторы - чисто дистрибуция по миру чужого value creation (хостеры тратили на капитальные инвестиции 25-50% выручки, это, в основном, шло Intel, AMD, Nvidia, Cisco и Broadcom)- Сейчас у нас эра хайпа, они вваливают в data centers по $80-100 млрд в этом году (при выручке в 2024: AWS $110 млрд, Azure 100, Google Cloud $50)- GPU живут 2-3 года, а рост выручки был в 2023-2024 15-30% (не такой быстрый) - верят, что в своих продуктах заюзают по мере внедрения AI?

Отказоустойчивость Шредингера - она считается реализованной и нереализованной одновременно, определяющим моментом являются незадекларированные возможности швабры тети Глаши в ДЦ.#мысли_вслух

Сегодня я узнал, почему у меня на ноуте VPN не давал подключиться к большей части релевантных сайтов...Оказывается, у меня был включён IPv6. Мой клиент Outline создавал впн-подключение на IPv4 интефейсах, а на подключение по IPv6 никак не влиял.Почему это плохо? Потому что всякие фейсбуки да опенэйай имеют оба вида IP-адресов. Когда ваш комп поддерживает только древние стандартные короткие IPv4, айпи-адреса (типа 123.45.67.8), то подключаетесь вы по этому протоколу. А если есть возможность переключиться на более новый, более модный и более замороченный IPv6 (с длинными адресами типа 2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d), они предпочитают работать с ним. Но такое подключение оказывается за пределами VPN.Внешне это проявлялось по-разному. Где-то возникала краткосрочная иллюзия, будто сайт заработал, где-то ошибка возникала сразу. Честно говоря, если бы сайт openai не рассказывал бы мне, что мой подозрительно длинный IPv6-адрес забанен, я бы вообще не понял, в чём дело.Но ура, я отключил себе IPv6, и теперь снова могу выходить в свободный интернет.Даёшь интернет без ограничений и цензуры! Ну, вы сами знаете, кто и что себе должен заблокировать.#программистское

#Docker 2024Docker. Вводный курсАвтор: Кейн Ш.П.Книга подробно описывает инструментарий Docker и возможности использования контейнеров для развертывания программного обеспечения. Рассказано об интеграции Docker и контейнеров Linux с облачными сервисами и Kubernetes. Описаны методы сборки образов Open Container Initiative (OCI), развертывания и администрирования образов с использованием командной строки. Показано, как образы OCI упрощают управление зависимостями и ускоряют процесс развертывания приложений. Даны практические рекомендации по настройке и тестированию контейнеров, подробно рассмотрены инструменты оркестрации, обеспечения безопасности и конфигурирования Docker. В третьем издании особое внимание уделено инструменту BuildKit, поддержке мультиархитектурных образов, а также контейнеров в режиме rootless.

ЖЕЛДОРРЕММАШ ПЛАНИРУЕТ В 3 РАЗА УМЕНЬШИТЬ СКЛАДСКИЕ ИЗДЕРЖКИ БЛАГОДАРЯ ЦИФРОВИЗАЦИИ⚙️ Компания запустила проект по внедрению терминалов сбора данных (ТСД) на заводских складах. Движение товарно-материальных ценностей будут фиксировать в реальном времени. Цифровая трансформация складских процессов ускорит процессы приёмки, отгрузки и инвентаризации, снизит влияние человеческого фактора при ручном вводе данных. 🏭 На Оренбургском ЛРЗ внедрение ТСД началось в конце 2024 года. Были закуплены терминалы и ремаркировочные принтеры, проведена интеграция с программным обеспечением 1С ERP, а персонал обучили работе с новым оборудованием. Какой эффект планирует получить Желдорреммаш по итогам автоматизации складской логистики к 2027 году:1️⃣ уменьшение складских издержек в 3 раза, 2️⃣ увеличение скорости сборки товаров - на 100%, 3️⃣ эффективность использования трудовых ресурсов вырастет на 20%,4️⃣ количество ошибок отбора товаров уменьшится на 30%. #КлубЭБС #цифровизация #автоматизация_логистики

Сайт реестрповесток.рф также заработал для всех военнообязанных.Протестировать отправку сведений в ВК через Реестр пока не удалось, зато удалось протестировать Реестр военнообязанных для физлиц.Доступ к личному кабинету происходит через верификацию на Госуслугах.✅ На сайте военнообязанный может запросить:1️⃣ Выписку из Реестра повесток, т.е. узнать выписаны ли повестки в его отношении.2️⃣ Выписку из Реестра ВУ, которая впоследствии будет содержать 50 атрибутов различных сведений.На тех, кого еще не внесли в Реестр ВУ содержатся следующие сведения:- ФИО- Дата рождения- СНИЛС- Регистрационный номер и дата ВыпискиВыписка подписывается электронной подписью МО РФ.✅ В Госдуме сейчас рассматривается законопроект, приравнивающий Выписки из Реестров к документам воинского учета, к которым сейчас отнесены:- ВБ- ВБ офицера запаса- Приписное удостоверение призывника- Справка взамен ВБ- Временное удостоверениеВполне возможно, что скоро, мы будем при трудоустройстве и сверках - требовать актуальные Выписки из Реестров, вместо документов ВУ, в которых куча недостатков. ✅ Дополнительно на сайте реестрповесток.рф можно узнать о наличии временных ограничений:- Ограничение на выезд за пределы РФ- Ограничение на управление ТС- Ограничение на регистрацию ИП- Ограничение на получение кредитов (займов)- Ограничение в постановке ТС на учет- Ограничение в регистрации недвижимости* Повестка, направленная через Реестр, автоматически считается врученной, через 7 дней после ее регистрации.** Временные ограничения наступают через 20 дней после неявки ВК, для призывников выезд за пределы страны ограничивается с 1-го дня размещения повестки в Реестре. *** Временные ограничения снимаются в течение суток после посещения ВК.✅ Дальнейший путь по внедрению Реестров:- Отладка механизмов направления организациями сведений и принятия их ВК- Наполнение Реестра военно-учетными данными на всех военнообязанных- Активное использование электронных повесток и ограничений за неявку по нимВоинскийучёт.рф

После новостей про прекращение поддержки Grafana OnCall, а теперь аннонса поглащения Keep, вижу разговоры про "закрытие очередного проекта". Обращаю внимание на цитату из аннонса: "Keep будет интегрирован с эластиком и кибаной, его исходный код останется открытым."На данный момент, для коммьюнити все выглядит очень хорошо. Проект получает ресурсы крупной компании, есть заявление о намерении инвестировать в OSS. А что самое интересное, эта компания недавно заново осознала важность OSS и сменила лицензию своих основных продуктов на более открытую.

Почему нельзя делать загрузку сайта на боевой сервер в пятницу?В разработке интернет-проектов есть золотое правило — не выгружать наработки на основной сервер в пятницу. Особенно, если вы сделали новый сервис или сайт взамен старого. Потому что сделать сразу на 100% рабочий продукт сложно, и обычно, мелкие баги быстро появляются и мешают работе сайта в выходные.По итогу в выходные вся команда пашет, потому что кто-то сделал выгрузку в пятницу :)Сегодня хоть и не пятница, но выгрузку тоже не стоит делать. Особенно, учитывая, что впереди 4 выходных. Мы даже мем сделали для нашего разработчика Андрея.

Стоимость мобильной связи и интернета в разных странахВ 2024 году мировой рынок телекоммуникаций вырос на 3,3% и достиг $1,18 трлн. Спрос на услуги связи формирует различия в стоимости мобильного интернета и тарифов по странам.Все мы знаем, что в РФ один из самых быстрых и доступных интернетов в мире. За $6–15 можно получить безлимитный интернет на приличной скорости, иногда в эту сумму входят мобильная связь и ТВ (в подарок). А как обстоят дела у других?США: высокая конкуренция и переход на 5GРынок телекоммуникаций США — один из самых крупных и конкурентных. Цены формируются под влиянием технологических изменений (переход на 5G) и слияний операторов.Средняя стоимость мобильного тарифа — от $30 до $70 в месяц. Высокоскоростной интернет доступен в большинстве регионов, цены и скорости сильно варьируются.ЕС: борьба с монополиями и отмена роумингаВ ЕС тарифы регулируются на уровне Еврокомиссии, которая строго контролирует слияния операторов для предотвращения монополий. С 2017 года действуют правила "Роуминг как дома", отменившие плату за роуминг внутри ЕС. Широко распространены безлимитные тарифы (4G/5G). Стоимость домашнего интернета зависит от региона: в Германии и Франции он дешевле, чем в сельской местности (логично: чем больше пользователей, тем дешевле услуга).Китай: госрегулирование и дешёвый интернетРынок связи в КНР отличается жёстким госконтролем, что позволяет реализовывать масштабные проекты, например, развитие 5G. Средняя цена мобильного интернета — от $0,2 до $0,3 за 1 ГБ, а безлимитные тарифы стоят от $12 до $20 в месяц.Государство субсидирует внедрение цифровых технологий, делая связь доступной для населения.Индия: самый дешёвый мобильный интернет в миреБлагодаря жёсткой конкуренции Индия предлагает самые низкие цены на мобильную связь. Средняя стоимость мобильного интернета — $0,17–0,20 за 1 ГБ.Тарифы с 10–30 ГБ обычно стоят $3–5 в месяц. Операторы часто предлагают большие объёмы трафика (до 50–100 ГБ) вместе с безлимитом на звонки и SMS по низким ценам.Азербайджан: госрегулирование тарифовВ Азербайджане доминируют три оператора (Azercell, Bakcell, Nar Mobile), предлагающие разные тарифные планы.Широкополосный интернет в городах развит, но в сельских районах есть проблемы (как и везде). Средняя цена домашнего интернета — $16,59 в месяц (для сравнения: в Турции — $8,77, в Молдове — $9,14).Казахстан: рост цен на мобильную связьНесмотря на конкуренцию между Kcell, Beeline и Tele2, с начала 2024 года цены на тарифы выросли в среднем на 25%.С апреля 2025 операторы повысили стоимость услуг на $1–3, объясняя это затратами на модернизацию сетей. При этом Казахстан остаётся страной с дешёвым мобильным интернетом: 1 ГБ в среднем стоит $0,59 (в Таджикистане — $1,65, в Узбекистане — $0,60, в Кыргызстане — $0,17).Аналитики Analysys Mason прогнозируют дальнейший рост рынка: в 2024 году выручка увеличилась на 2% по сравнению с 2023 годом. Доходы операторов растут за счёт того, что люди всё больше платят за интернет и мобильные данные. Вложения в оптоволокно и спрос на быстрый интернет увеличат средний чек за домашний интернет. Мобильный рынок США будет расти быстрее, чем в Европе.Одним из ключевых трендов остается внедрение 10G сетей, первые из которых уже запущены в Китае.Местные операторы, например в РФ, находятся под сильным давлением из-за ослабления национальной валюты — например, рубля. Их выручка сильно падает, когда рубль дешевеет по отношению к доллару, а нарастить цены с такой же скоростью, с какой рубль идёт вниз, им не удаётся.Оценка получилась спорной. Например, в Индии можно приобрести мини-пакет (0,5–1 ГБ) мобильного интернета за указанную цену, тогда как для большинства стран просто рассчитывается средняя цена.Разбивку по средним ценам за 1 ГБ мобильных данных в разных странах в 2023 году можно изучить тут (1-е место: Израиль — $0,02, 15-е: РФ — $0,25, последнее (237) — Зимбабве — $43,75).Источники: qazinform.com, mordorintelligence.com, point-topic.com, mydrivers.com, bestbroadbanddeals.co.uk👍 Капиталистический Ватник. Подписаться

Ну что, москвичи, вдохнули свежего воздуха за эти полтора часа без интернета?Я вот вдохнул 😶

Про "позеленение" и Свету¡Viva la transición verde!Ура испанскому зеленому переходу! Ура всем, несущим несусветную пургу о произошедшем на Иберийском полуострове, начиная с испанского премьера и заканчивая доморощенными конспирологами в интернете!Вернемся почти 20 лет тому назад. В Европе жили не тужили, радовались дешевой энергии и только время от времени занимали себя мыслями о глобальном потеплении. Это РЕЗКО изменилось к концу 2000-х. Официально – из-за того, что "ученые" возопили, что мы все или потонем в поднимающемся море, или сгорим в пламени глобального потепления.Однако, глядя на то, что было сделано в ЕС в следующие 15 лет, становится ясно, что мантры про окружающую среду – блеф, а реальная цель – подготовка Европы к конфликту с Россией. Европа предполагала, что Россия будет использовать газ как оружие, и начала готовиться – "зеленеть".Если у кого-то есть какие-то сомнения на эту тему, можно взять любую из ранних "стратегических экоразработок" 2000-х. Везде на почетном месте стоит так называемый residential demand-responsе – балансирование сети с помощью регулировки потребления домохозяйств. В те времена витали всякие безумные идеи, что скоро появится "умная" техника, которая будет уважать сигналы от сети и ставить стиралку на паузу в часы пик. Идея была: приучить Педро, Джона или Анну-Лизу к тому, что рубильник их дома будут дергать без их согласия и это нормально. Все во имя окружающей среды... И для этого Педро, Джону и Анне-Лизе поставят "умный счетчик" с встроенным выключателем, который может при необходимости их выключить из сети.Тогда эти идеи выглядели безумно. Сейчас? Всем ясно, что с природой это не имело ничего общего, а Европу готовили к конфликту. Demand-response в спальных районах как метод экстренной балансировки сети, после того как из нее выпали гигаватты? Попахивает порохом и тротилом.Никто не дал инженерам реального техзадания "резать потребителей после удара ракеты по сети". Вместо этого им дали какую-то зеленую фантасмагорию. Ну и результаты налицо: ни одна система demand-response через потребительские "умные счетчики" не в состоянии работать по предназначению. Вырубить электричество, если не платишь, – могут. Вырубить его в реальном времени в необходимом количестве для балансировки сети? Забудь. Коммуникации не в состоянии нести необходимое количество команд в секунду.После начальных инвестиций об этом как-то забыли и ударились во все тяжкие с другой половиной зеленого перехода – генерацией. Все ринулись в солнце и ветер как замену газу. Это довели до вполне приличных процентов зеленки, но они все еще были недостаточны для "готовности к конфликту с Россией". И тогда ЕС постановил, что "где-то над Европой светит солнце и где-то дует ветер", стало быть, торговля через границу в состоянии убрать оставшиеся проклятые проценты зависимости от клятых москалей. Ветер и солнечные начали ставить "на экспорт".Испания – отличница зеленого перехода (хотя они не единственные, им в спину дышат несколько других стран). Они присобачили солнечные панели везде, где смогли, – даже на крышах автобусных остановок и парковок. В результате некоторые человейники в солнечный день вырабатывают наравне с большой электростанцией. Авангардно. Зелено. Молодежно. Но... в банке меда есть большая ложка дегтя – все это контролируется через те же "умные счетчики". Просто сброс генерации вместо сброса потребления. В остальном проблемы те же – система управления не может справиться с большим числом заявок.Остальное было вопросом времени. Штиль. Прохладный день, когда испанец уже не включает отопление, но не включает и кондей. Солнце. И решение дать солнечной разогнаться, вместо того, чтобы начать сбрасывать генерацию отдельных панелей еще с утра. Гигаватты солнечной в сеть. И в какой-то момент сработала автоматика безопасности. И Света ушла из страны.Это будет повторяться. Инфраструктура и конкретно системы управления не проектировались для такого использования. "Браво! Бис!" Повторение не заставит себя ждать.

«Работает — не трогай»? Почему процессы нужно проверять на прочность заранееМне тут прислали кейс от FlowWow — у них легла вся логистика и служба поддержки, заказы не доставлялись вовремя (или вообще) более суток. Системный сбой. Вы можете спросить:«Таня, это же техническая проблема, что они могли сделать заранее?»Отвечаю:Антикризисное реагирование на 90% состоит из превентивной работы.➡️Что произошло у FlowWow?информация о сбое не дошла до руководства сразуникто не признал проблему на стартене было чётких инструкций, не было понимания, что делатьне сработал механизм экстренного оповещения и реагирования, потому что он либо не был предусмотрен, либо никогда не проверялся вживуюИ вот тут ключевой момент.Все процессы до сбоя «работали». Видимо. Никто их не трогал.Пока не стало ясно, что под нагрузкой они не держатся вообще.И это то, что происходит в сотнях компаний.«У нас всё нормально и мы даже не будем думать, что что-то может пойти не так».Так не работает кризисное управление. И не только кризисное, так в принципе не работает адекватное управление!Процессы нужно проверять заранее.Не тогда, когда уже всё горит. А в моменты тишины.Не «если случится» — а «когда случится, кто и как об этом узнает первым и что мы будем делать».Для этого нужно:➡️ превентивная работа и готовность вкладываться ДО того, как всё пойдёт не так➡️ структура, по которой информация доходит моментально➡️ культура, в которой допустимо говорить, что что-то не работает➡️ регулярная проверка процессов не на «могут ли они работать», а на «могут ли они выдерживать сбой»Я всегда говорю: если вам кажется, что у вас всё стабильно — именно сейчас стоит проверить, где в системе слабое место. Потому что проверка под реальной нагрузкой может стоить вам репутации.FlowWow — хороший пример.Они не сделали ничего плохого. Они просто не тронули то, что «работало» — до тех пор, пока это не перестало работать совсем.А у вас процессы проверяют заранее? Или трогают только тогда, когда уже поздно?

🧩 Банки больше не банки. Бренды — не просто бренды. Что происходит?Когда топовые компании — от банков до спортивных гигантов — начинают действовать как продуктовые ИТ-команды, это не мода. Это технологическая эволюция.Раньше бизнесы выстраивались вокруг продуктов. Сегодня — вокруг платформ.Платформа — это не «система» и не «интеграция». Это среда, которая позволяет масштабироваться без анархии и тормозов.Вместо того чтобы заново разрабатывать авторизацию, UI-компоненты, логгеры и CICD — вы берёте всё это из единой библиотеки. Повторное использование становится стандартом.🧠 Почему компании массово переходят на платформенный подход:1. Избавление от технического долга по умолчаниюПлатформенные команды задают стандарты, обновляют их централизованно и обеспечивают обратную совместимость.Это убирает хаос, когда каждая продуктовая команда решает одни и те же проблемы по-своему — плохо, дёшево и несовместимо.2. Резкое снижение «времени до ценности»Команды больше не тратят время на обвязку. Они концентрируются на том, что получает клиент, а не на борьбе с инфраструктурой.Время от идеи до MVP — не 3 месяца, а 3 недели. Это уже норма у технологических лидеров.3. Выход из ловушки человеческого ресурсаБез платформы масштаб = найм. С платформой — масштаб = повторное использование.Команды с 4-5 инженерами могут делать то, что раньше требовало 10–12. А значит — не выгорают и не бегут.4. Опциональность, а не диктатПравильная платформа не навязывается, а «продаёт себя» через удобство.Gartner называет это «приглашённой дорогой»: если платформа удобнее ручной сборки — команда по ней пойдёт.📈 Реальные эффекты от перехода:+50% скорость вывода новых фич (данные ThoughtWorks)–40% отказоустойчивых инцидентов+25% удержание инженеров–30% косты на поддержку инфраструктуры+ рост NPS внутри команд разработки🚀 Примеры из индустрииNike построила платформу для управления контентом и кастомизацией под регионы — это ускорило запуск новых коллекций в 4 раза.Goldman Sachs создал инфраструктурную платформу для трейдинга — теперь команды работают как продуктовые стартапы внутри банка.Spotify внедрил принцип «платформа как продукт» — с выделенной roadmap, ресерчем, user interviews и метриками CSAT.🤖 А теперь — следующий уровень: GenAI внутри платформПлатформа становится не просто набором сервисов, а интеллектуальным интерфейсом, где разработчик:- описывает, что нужно,- получает готовую конфигурацию,- запускает — и тестирует не руками, а через AI-сценарии.Это не гипотеза. Уже сейчас GitHub Copilot, AWS Bedrock и Google Cloud Duet интегрируются в платформенные пайплайны.⚡️ Подписывайся на Канбан Клуб. Пассивное обучение. Читаешь — и растёшь.

Универсальный стек для работы без Docker ComposeУдивительное рядом. Как оказалось, многие разработчики зашли в разработку когда в их проекте уже был Docker Compose и они не видели других способов работы. Когда-то я рассказывал как перейти на Docker Compose, а теперь пришла пора говорить о том, как работать без него :)Docker Compose, в первую очередь, нужен для унификации среды разработки, чтобы сетап был единым независимо от того, где вы его разворачиваете и что там на машине было установлено. Как ни странно, все это было и до него, например через Vagrant (Кто еще застал разработку через него?). Переход на Compose произошел из-за повального движения в сторону легковестных контейнеров, а не полноценных виртуальных машин. К тому же Docker становился стандартом в продакшене, что давало возможность переиспользовать Dockerfile для разработки и продакшена. Но реальная жизнь оказалась сложнее. По порядку:1. Единый Dockerfile для продакшена и девелопмента это миф и работает только в примитивных случаях2. Постоянные сложности с настройкой сервисов, так как работа внутри контейнера часто требует особой конфигурации, запуска в хедлес режимах и указания специальных переменных окружений.3. Compose значительно усложняет процесс разработки: внутри/снаружи, установка зависимостей, персистентность (игра с волюмами).4. Compose требует шаманств в работе с редактором. Чтобы заставить работать lsp сервера и линтеры, нужно научить их ходить во внутрь контейнера, либо как-то имитировать идентичный сетап снаружи.В итоге решая буквально одноразовую задачу по первоначальному сетапу, Compose значительно ухудшает сам процесс разработки, с которым мы сталкиваемся каждый день. Можно ли отказаться от него, не потеряв те преимущества, которые он дал? На 100% нельзя, но можно сделать достаточно хороший сетап, который уберет большую часть проблем и точно будет намного приятнее в использовании. Что для этого надо?1. Автоматизация команд с зависимостями. Тут берем Make или его аналог https://www.youtube.com/watch?v=pK9mF5aK05Q2. Mise - универсальная тулза для установки языков: https://mise.jdx.dev/ 3. Overmind: Менеджер процессов, позволяет запускать наборы сервисов как DC: https://github.com/DarthSim/overmind (раньше для этого использовали Foreman, формат кстати остался тот же)4. Как ни странно тот же Docker. Например не имеет смысл ставить базу прямо в систему, ее можно запускать так же в контейнере, но без ComposeВсе это можно подсмотреть в нашем продакшен проекте https://github.com/hexlet-basics/hexlet-basics/blob/main/MakefileЧто еще? Пожалуй главная засада это первоначальная настройка вашей операционки. В маке что-то надо поставить через brew, в ubuntu через apt. Но опять же, решается все это крайне просто через тот же Make:macos-setup: brew install overmind caddyНо даже в этом случае, подготовить сетап не сложнее чем написать docker-compose.yml (в реальности последний написать сложнее, если это связано с конфигурацией сервисов под работу внутри контейнеров). А вот использование будет на порядок проще.Ссылки: Телеграм | Youtube | VK

Чему мы можем научиться у Amazon Elastic Block StoreAmazon EBS — сервис блочного хранения. Он входит в экосистему AWS и используется для работы с большими объемами данных. Сейчас это огромная распределенная система SSD, которая обрабатывает 140 триллионов операций.Сервис начал работу в 2008 году — и тогда, он, конечно, был совсем другим. Марк Олсон, инженер, который работал над EBS больше 10 лет, рассказал, как проект менялся и развивался с годами. Это не только повод поностальгировать по тем далеким временам, но познакомиться с подходом Amazon к решению проблем и внедрению изменений.Несколько полезных инсайтов из статьи:🔵Развитие EBS — постоянный и постепенный процесс. Возможно, для кого-то это и так очевидно, но это одна из главных мыслей всего лонгрида: сервис менялся и дорабатывался на протяжении всего времени существования, чтобы в итоге прийти к 140 триллионам операций. Одним героическим рывком к таким масштабам не прийти.🔵Один из ключевых вызовов перед командой проекта — это найти баланс между надежностью, производительностью и удобством для пользователя. Необходимость заботиться обо всех этих факторах (а не только о надежности в ущерб скорости) обуславливала многие решения и подходы, которых придерживались разработчики.🔵Производительность системы зависит от множества факторов и изменения только на одном уровне, даже очень масштабные, могут не принести желаемого эффекта. С этим команда столкнулась, когда переехала с HDD на SSD. Пришлось апдейтить остальные компоненты системы, чтобы добиться прироста роизводительности.🔵Full-stack-инженер, который умеет все, — это, конечно, круто, но когда речь идет про работу над такими сложными системами, как EBS, узкие специалисты, которые детально разбираются в своей конкретной области, могут быть ценнее.🔵Если хотите, чтобы ваши инженеры (и вообще любые сотрудники) хорошо работали, нужно создать условия, при которых они смогут не бояться экспериментов и выходить из зоны комфорта.Как вам опыт Amazon EBS?❤️ — Есть чему поучиться!🌚 — Ну такое…

Есть вот такой кампус (на первой картинке), что будем делать?Правильно, MPLS, EVPN, SDA. (вторая картинка).Нормальные стойки под оборудование, кабель менеджмент, эксплуатацию которая этим всем занимается - нет, спасибо. Лучше обмажемся VXLAN... Отличный план!Ну это я немного утрирую конечно, они там сначала предлагают просто обычную сетку сделать, а уж потом ненавязчиво вкидывают про EVPN и его поддержку на новой линейке каталистов, которую вы теперь себе мечтаете купить :)Но в целом, преза нормальная, показаны и простые сценарии и чуть поинтересней, для ознакомления можно полистать, оставил вот тут - https://likeabus.ru/assets/docs/BRKENS-1501.pdf

PAM в ssh_configПривет!Недавно взял себе сервак на 2 Гб RAM на JustHost. По деньгам как DigitalOcean, только памяти в 2 раза больше.Настроил как обычно (создал юзера, отключил вход для рута и по паролю). Но через пару дней при проверке обнаружилось, что по паролю все еще можно войти. Чатгопоты посоветовал отключить PAM в настройках ssh_config. Я особо не шарю, отключил - заработало!И тут на днях настраиваю dokku для деплоя по своей инструкции, но запушить в dokku не могу, ругается на публичный ключ. Все ключи прописаны, права у юзеров в порядке, конфиги тоже. Но все равно ругается на публичный ключ. Спустя пару дней поисков и переписок с чатом закралась мысль, что дело в PAM. Причем этот АI пес даже не предложил такой вариант🤨Кароч, как оказалось, PAM — это модуль отвечающий за аутентификацию. Не особо проникся его плюшками, но без него аутентификация проводится силами самого ssh сервиса, и, видимо, как то урезанно и негибко.Морали нет, просто буду иметь в виду 😁Кто шарит в теме, поясните почему без него не работает))

Друзья, продолжаем рубрику "Слово недели". Сегодня поговорим о деплое программного обеспечения. 😵‍💫🟪Деплой (от англ. deploy — развертывание) является одним из ключевых этапов в разработке ПО, который связывает написание кода и его реальное использование. Задеплоить — это значит сделать программу доступной для пользователей. К основным этапам деплоя ПО относятся:▫запуск и настройка сервера▫проверка системы на работу в имитации реальных условий▫организация доступа для реальных посетителей и клиентов▫мониторинг (отслеживание состояния системы)Деплой ПО обеспечивает:1⃣доступность ПО для пользователей: без деплоя код останется просто текстом на компьютере разработчика2⃣обновления и улучшения ПО: деплой позволяет внедрять новые функции, исправлять ошибки и улучшать производительность кода 3⃣автоматизацию процессов: современные подходы к деплою позволяют автоматизировать рутинные задачи, что ускоряет разработку и снижает вероятность ошибок4⃣масштабируемость системы: деплой помогает адаптировать приложение под растущие нагрузки, добавляя новые серверы или ресурсыВ небольших компаниях деплоем обычно занимается бэкенд-разработчик. Чаще всего это самый опытный сотрудник, который знает все о сервисе. В более крупных организациях деплоем занимаются DevOps-разработчики.👩‍💻 Примером популярных инструментов для деплоя ПО является Docker — платформа, которая позволяет упаковать приложение в контейнер со всем необходимым окружением, а затем доставить и запустить его в целевой системе.Ставьте реакцию:🔥 — если знали, что такое деплой👀 — если слышите этот термин впервые🔝🔝🔝Сохраняйте пост в избранное, точно пригодится! ✍🏻#словонедели #поколениеpython

Кто такие SRE инженеры и как они делают стабильностьО чём думаю, о том пою. А на работе сейчас думаю о росте качества и стабильности наших цифровых каналов (это корпоративно-правильное название человеко-понятного термина интернет-банк для mobile и desktop, ну и для API).Тут писал, что мы планируем качать сразу несколько направлений по снижению даунтайма, и в этом посте хочу рассказать про новую роль в команде — SRE-инженер. Кто-то из подписчиков кинул мне в коммент, что это "стандарт отрасли" и что ему нас очень жалко.Штош... ничто не мешает нам сегодня быть лучше, чем мы были вчера 🤓Так кто же такие SRE-инженеры?Типовая команда разработки состоит из программистов всех мастей, тестировщиков (функциональных и нагрузочных), системных, продуктовых, а иногда и бизнес-аналитиков, дизайнеров и PO. Чтобы совсем было хорошо, ещё нужны UX-исследователи, CX-эксперты, а чтобы выжить в Enterprise-среде — админы, безопасники и, конечно, архитекторы. Это далеко не все роли — есть ещё много специальностей.Наша клиентская база супер активно растёт. Мы второй банк по количеству клиентов — считай, первый :)Количество продуктов и активность внутри растет ещё большими темпами. Очевидно, что такой бурный рост даёт сверхсильную нагрузку на наши сервисы.Понятно, можно заливать всё железом, оптимизировать процессы, делать нагрузочные тесты (но синтетические изолированные тесты всю картинку не дают). Мы уже решили пойти в chaos-тестирование (об этом потом, если интересно). Но ещё важно прокачать компетенцию в команде, которая будет концентрировано заниматься стабильностью и доступностью сервисов.Имя этим бойцам — SRE (Site Reliability Engineer). Это инженер, ответственный за надёжность, производительность и стабильность. По сути, это или разработчик, который умеет в админство, или админ, который умеет в разработку. Он не пилит кнопочки на фронте, а исключительно оптимизирует производительность и отказоустойчивость своих систем.Я знаю один банк, где есть такие бойцы (ребята, мой вам респект!). А вообще родина SRE — это Google. В 2016 вышла одноимённая книга про этих ребят.🔠🔠🔠🔠🔠🔠Вдруг среди моих читателей есть такие супер-инженеры? Или вы знаете таких?Знайте и передайте — мы вас ищем. Писать можно в личку мне (@exqui).🦄 Продолжай про стабильность. Что у вас по chaos тестированию🌭 Если уж про работу, то лучше про продукт менеджмент🗿 Пощади, про такое после 19 не надо.

Мы можем сколько угодно хвалить бойцов нашего доблестного (нет) РКН, но Испания не отстаёт от наши бравых солдат — на выходных там тупо заблокировали все IP'шники Cloudflare по постановлению суда в попытке заблокировать пиратские сайты с вещаниям футбола. Огребли и создатели Vercel, и куча других сайтов.Как бы да, можно сколько угодно рекомендовать "не хоститься рядом с теми, кто распространяет нелегальный контент", но ты про это даже не знаешь в общем случае. К тому же, как в случае с Vercel, их даже не предупредили заранее, т. к. нарушали то не они, а другой сайт. Ребята просто попали под веерный бан, т. к. общий IP с сайтом, нарушающим закон.

👨‍💻 Скрипты для CloudflareУ нас щас 400+ сайтов под США. Каждый сайт имеет свой собственный аккаунт в Cloudflare. И если что-то в настройках поменяется, то это ппц сколько времени я на диване не полежу. Пришлось писать скрипты. Пока их всего 4 штуки.Для всех скриптов нужны API и почта аккаунта.🌐 Изменение IP в DNSУже пару раз переезжал на другой сервер и приходилось менять IP в настройках Cloudflare. Для этого был сделать скрипт.Работает он так:1. Вносится список API в файл apis.txt.2. Вносится список почт в emails.txt. 3. Вносится IP в файл ip.txt. Только один.4. Запускается скрипт.5. Меняется IP в каждом аккаунте 🥳🖥 Получение NS каждого аккаунтаИмпортируются NSы каждого аккаунта в табличку csv: в ней домен, ns1 и ns2.Использовал, чтобы вручную не копировать это из аккаунтов. Даже логи пишутся.Работает он так:1. Вносится список API в файл api.txt.2. Вносится список почт в emails.txt.3. Запускается скрипт.4. Получаем табличку с данными 🎉🤖 Включение Bot Fight ModeБыли проблемы с нагрузкой сервера, пытались решить отсечением левых ботов.Я плохо помню каких ботов он там фильтрует - каких-то неизвестных для CF ботов.Работает он так:1. Вносится список API в файл api.txt.2. Вносится список почт в emails.txt.3. Запускается скрипт.4. Включили режим защиты от ботов 🍾🤖 Блокировка сеошных ботовВсё с той же целью отрубали ботов - думали поможет снять нагрузку на сервак.Фильтрует ботов semrush, ahrefs и прочих.Кто шарит вот само правило: (cf.verified_bot_category eq "Search Engine Optimization") or (cf.verified_bot_category eq "AI Crawler") or (cf.verified_bot_category eq "AI Search")Работает он так:1. Вносится список API в файл api.txt.2. Вносится список почт в emails.txt.3. Запускается скрипт.4. Защита активирована. Не пройдёт ни один автобот 🤖Буду рад репостам и лайкам 😃😍 Подписаться на alexadi #программирование #скрипт #cloudflare

Go планирует улучшить производительность в контейнерах (proposal)GOMAXPROCS - это настройка в Go, которая определяет максимальное количество CPU-ядер, используемых для выполнения горутин параллельно. В Go 1.25 разработчики предлагают встроить умный GOMAXPROCS, который будет учитывать ограничения контейнера (cgroup). Сейчас Go автоматически устанавливает GOMAXPROCS равным всем логическим ядрам на машине, что создаёт проблемы в контейнерах, где доступно меньше ресурсов. Это приводит к неэффективной работе, проблемам с производительностью и троттлингу приложения.Проблема актуальна для всех, кто запускает Go-приложения в контейнерах (Docker, Kubernetes), и остро стоит в окружениях, где на одной машине запускается много контейнеров с ограниченными ресурсами.Сейчас разработчики решают эту проблему ручной настройкой через переменные окружения или используя библиотеку от убера. Новое предложение добавляет в сам Go автоматическое определение ограничений CPU из cgroups и динамическое обновление GOMAXPROCS при изменении этих ограничений.🫥 Cross Join⠀#golang #performance #kubernetes #docker

Как работают вызовы API внутри сервера.Когда рассказывают про интеграции и про API, обычно сервер рисуют как черный ящик. Вот в него входят HTTP-запросы, дальше говорим про URI, параметры, схемы данных.Но для новичков иногда непонятно, чем отличаются разные технологии. Однажды на тренинге по интеграциям мне задали вопрос: про Кафку мы поняли, её нужно ставить как дополнительное ПО. А вот gRPC — он тоже ставится на отдельный сервер?..Тут, кажется, стоит вернуться к основам, попробовал нарисовать.Клиент обращается к серверу (1). Сервер — это компьютер, у него есть сетевая карта (или даже несколько), у карты есть IP-адрес. На него из сети приходит запрос. В запросе указан порт. Операционная система смотрит по своей таблице портов, в какой из запущенных сервисов отправить этот запрос (2). На одном порту отвечает только один сервис. Всего TCP-портов может быть 65535, то есть один сервер может отвечать по-разному на разных портах. Связь порта и сервиса называется биндинг, приложение при запуске пытается этот биндинг создать и дальше "слушать" порт, то есть ждать из него сообщений.Стандартные порты — HTTP:80, HTTPS:443. То есть, всё, что приходит на 443, будет отправлено в HTTP-сервер, если он запущен. HTTP-сервер может быть встроен в приложение бекэнда, а может быть отдельным сервисом. Как правило, из соображений безопасности и производительности, в промышленном контуре HTTP-сервер отдельный. HTTP-сервер устанавливает зашифрованное соединение, проверяет корректность запроса и доступы. Дальше он пытается выполнить запрос. Есть три основных варианта:— просто отдать файл, лежащий на диске (3.1). Это называется "статика" — обычно это картинки или другие медиа, документы, HTML-страницы, стили, JS-скрипты. Статика отдается очень быстро (зависит от размера, конечно). Структура URL при этом не должна повторять структуру реальных папок на диске — мэппинг настраивается на HTTP-сервере.— выполнить скрипт, лежащий на диске (3.2). Эта технология называется CGI. Веб-сервер запускает скрипт, и отдает клиенту результат выполнения. Скрипт при этом может обращаться к БД или ещё что-то делать — это обычная программа. Так работают многие PHP-фреймворки. У HTTP-сервера должен быть установлен мод для запуска скриптов на конкретном языке (Perl, PHP и т.д.). На каждый запрос запускается свой отдельный экземпляр скрипта в отельном потоке.— передать запрос запущенному в памяти сервису (3.3) — приложению бэкенда (в UNIX-подобных системах он ждет запросов тоже по TCP, на каком-нибудь порту. Поэтому легко разнести HTTP-сервер и сервер приложений на разные машины, если понадобится). В сервере приложений в ответ на входящий запрос запускается функция роутинга всех входящих запросов, которая парсит заголовок запроса и вызывает соответствующую функцию (метод) у себя внутри (4). Эта функция уже делает всё, что нужно, чтобы обработать запрос и выдать ответ: обращается к БД (5) или к внешним сервисам (6) — тогда ваш сервер приложений работает частично как шлюз API. Всё это может работать на одной машине, а когда нагрузка растет — мы разносим их по разным: HTTP-сервер, сервер приложений, СУБД. Теперь, где работает GraphQL? GraphQL — это замена вашему фреймворку для обработки вызовов на сервере приложений. Есть три варианта: встроить в ваш фреймворк — тогда ваш сервер приложений по одному из эндпоинтов будет отвечать как GraphQL; поставить отдельно в параллель вашему серверу приложений; поставить перед ним, как API-шлюз. Где gRPC? gRPC работает вместо вашего фреймворка, занимающегося парсингом входящих сообщений. HTTP-сервер, если он есть, будет проксировать TCP-трафик на ваш сервер, где его ловит gRPC и вызывает нужные процедуры.

🛤 BIM-Завтрак с Линейкой 🛣краткие тезисы:🐽 В нормах по биму бардак;🌉 Нет подходящего ПО для разработки ЦИМ мостов;🧾 От разных заказчиков разные требования (нужны однотипные);😈 Обратный бим зло, надо уйти от него (уже формируют рейтинг фирм "у кого качественнее обратный бим"🤣);📲 Пока лучший СОД это ватсапп и телега;🧚‍♂ Бим на стройке толкают малочисленные энтузиасты;🔍 Надо изучать ISO 19650;✅ Связка пир+смр даёт возможность сформировать требования по биму для нужд строителей;🏗 сдать ЦИМ в МГЭ = сделай проект стадии Р. 🟰 В общем все те же проблемы как и у проектировщиков зданий, только чуть хуже, в виду пока меньшего практического применения. 💖Очень понравилось общий правильный посыл:Бим должен быть в связке проект-стройка-эксплуатация и у всех должно быть ПОНИМАНИЕ "что и зачем?", тогда будут общие результаты, а не локальные.

#полезности17 фундаментальных метрик для IT командЗдравствуй, наблюдательный читатель! Ниже тебя ждёт краткое, но точное описание 17 метрик, разбитых на три группы — Crawl, Run, Walk — как в оригинальном списке от одной очень забавной компании, занимающейся ERP II трансформациями. Каждая метрика расскажет тебе, как лучше понимать скорость релизов, качество разработки, безопасность, а также ценность для пользователей и бизнеса. В конце — пользительные ссылкиCRAWL (базовые метрики существования)Deployment Frequency (DORA)Частота поставки нового кода в продакшен или конечным пользователям. Показывает регулярность релизов и помогает увидеть узкие места процессаLead Time for Changes (DORA)Время от коммита до развертывания. Если оно слишком велико, значит вы теряете адаптивностьChange Failure Rate (DORA)Доля изменений, после которых требуется откат или срочное исправление. Чем выше, тем больше говорит о проблемах качестваTime to Restore Service (DORA)Сколько уходит на восстановление работы после инцидента. Чем быстрее, тем выше устойчивость и меньше потерьTime Between FailuresСредний промежуток между сбоями. Позволяет оценить, насколько надёжным стал продуктRUN (стандартные метрики операционной эффективности)Flow TimeСколько занимает полный цикл задачи от идеи до продакшена. Выявляет «заторы» — длинные очереди или медленное ревью.Flow VelocityСколько задач в итоге доводится до завершения за единицу времени. Позволяет отслеживать «пропускную способность» команды.Flow EfficiencyКакую долю всего времени работы задача реально «делается», а не лежит в очереди. Низкий процент сигнализирует о больших простояхFlow DistributionРаспределение по типам задач (фичи, баги, техдолг и т.д.). Избегает перекосов: не забывайте о балансе между новыми функциями и качествомTeam HealthУсловный барометр морального состояния команды, её атмосферы и удовлетворённости. Мотивированная команда работает эффективнее и стабильнееMean Time to DetectЧерез какое время обнаруживаются неполадки или дефекты. Если долго, уязвимости могут «жить» в системе, создавая рискиNumber of VulnerabilitiesСколько уязвимостей найдено в коде/инфре. Чем оперативнее закрываются критические дыры, тем безопаснее продукт и спокойнее сонWALK (зрелые метрики фокуса на ценности)Customer NPSИндекс лояльности: показатель, насколько пользователи готовы рекомендовать продукт другим. Если NPS падает — звоночек, что люди недовольныTime to ValueЗа какое время клиенты получают реальную пользу от новой фичи. Быстрая выгода = довольные пользователи и рост продуктаService Level IndicatorsМетрики, отражающие качество сервиса (доступность, время ответа, процент ошибок). Задают SLO и смотришь, укладываетесь ли в эти целиDevelopment CostsВсе расходы, связанные с разработкой: зарплаты, инструменты, инфраструктура. Мониторинг затрат нужен, чтобы понимать ROI и не прожигать бюджетProduct AdoptionНасколько активно и регулярно пользователи пользуются новой фичой или продуктом. Высокое adoption = проверка ценности на практикеПолезные ссылкиhttps://www.aha.io/roadmapping/guide/agile/agile-metricshttps://www.gitclear.com/popular_software_engineering_metrics_and_how_they_are_gamedhttps://queue.acm.org/detail.cfm?id=3454124https://martinfowler.com/articles/measuring-developer-productivity-humans.htmlhttps://kaiten.ru/blog/f4p-framework/Отдельно выделю: unidraw.io/app/board/b05a2ae081007f362709 — где проделана замечательная работа по канбан-метрикам от деливери-менеджеров Т-банкаP.S. Поделись, что из этого ты уже измеряешь? Какие метрики на твой взгляд буллщит?

Закончена очередная большая переписка онлайн-курса "Системная инженерия", теперь это версия 2025 года, согласованная по идеям и терминологии со всеми курсами-пререквизитами.Основная цель текущей переписки -- это подробней дать идеи эволюционной инженерии, гибкой (agile) инженерной разработки. Существенно обновлены основные понятия: вместо "жизненный цикл", отсылающий к идеям однократного его прохождения и представлениям "водопада" идёт отсылка к "инженерному процессу" (engineering process, иногда в конкретизации software process или с отсылкой именно к разработке development process). В этой версии уточнено разделение труда: введена явно роль прикладного методолога (функционального проектировщика, функционального архитектора), уточнена роль визионера, уточнена роль инженера внутрненней платформы разработки (идеи DevOps дополнены идеями platform engineering). Инженерные обоснования, как главный технический тренд (после тренда автоматизации инженерии, в том числе с использованием AI) выведены в отдельный раздел. Объём текста (включая задания) -- 1Мзнак с пробелами (для сравнения: "Рациональная работа" -- 1.2Мзнака, "Системное мышление" -- 2.5Мзнаков, "Методология" -- 1.4Мзнака), текст был существенно дополнен разъяснениями и примерами (объём предыдущей версии курса -- 0.7Мзнаков, так что 30% материала в курсе -- новые). Разделы:Введение1. Безсмасштабная эволюционная системная инженерия2. Архироль создателя/инженера и разделение инженерного труда3. Инженерный процесс4. Прикладная методология предметной области5. Эволюционная архитектура6. Эволюционное проектирование7. DevOps8. Инженерные обоснованияОсновной материал курса изложен с использованием не столько стандартов системной и программной инженерии (они отражают идеи, которые были передовыми больше десяти лет назад, поэтому не отражают произошедшего с тех пор сдвига в эволюционную инженерию, но продолжают использоваться в сильно зарегулированных госорганами больших инженерных проектах создания кибер-физических систем типа атомной электростанции и авианосца, изменений инженерии там можно ожидать очень нескоро), сколько по современной литературе 2017-2025 годов. При этом в курсе нет фрагментов, сгенерированных AI-системами. В курсе приведено 392 ссылки на первоисточники и 21 обложка рекомендованных книг (картинка в посте в ЖЖ — как раз эти обложки, над каждой книгой — год её издания). https://ailev.livejournal.com/1759527.html

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

⚠️ Большой сбой в работе Yandex Cloud сегодняЗона ru-central1-b полностью недоступна по питанию, авария с системой энергоснабжения😱 А теперь угадайте в какой зоне мы с командой хостим бекенд наших сервисов ?🤮 Наши приложения полностью "лежат" уже 6 часов так что это репортаж с места событий

Я хотел сделать лайтовый пятничный "Пыльный чулан" про забавную физику, но посмотрел на пост про распределенные системы и решил дать вам ПОБОЛЬШЕ ХАРДКОРА.Сегодня достаём разговорчики про перфоманс в основном внутри одной машины.Не так уж и давно я решал SRE Week от Яндекса. Там были задачки на перфоманс.- оптимизированный под разного размера массивы бинпоиск. Чуть подробнее о бинпоисках я писал когда-то давно, пригодилось- потом была spsc queue на C++, rate limiter на golang и задача, которую я не решил из-за лени. Для лучшего понимания memory ordering'ов в очереди стоит почитать пост с картинкой Serializable vs Linearizable и приправить постом про барьеры памяти.Про отношения между latency и throughput (пригодится с рейт лимитером) есть (имхо) красивая аналогия в соответствующем посте.- последний блок задач был на исследование проблем с производительностью с помощью bpftrace — там типичная история из жизни performance инженера, когда ты мерил, мерил, но мерил не то 🤡Постов про bpftrace у меня нет, поэтому я просто порекомендую постом книгу Дениса Бахвалова про перфоманс и микрооптимизации с массированным использованием perf'а. Заодно разберетесь со всякими там фронтендами и бэкендами процессора. А для подготовки к этой книге, стоит прочитать (если еще не) WEPSKAM (хотя лучше pdf найдите).Вне категорий ещё неймдроппинг:- Brendon Gregg, System Performance, которую я украл у Серёги- Peter Sewell, статьи из раздела Relaxed-memory concurrency, кладезь золота, которую мне открыл ШипилёвЕсть ещё, но мне кажется, что уже этого вполне достаточно, чтобы забить себе башку на месяца вперёд))