DevOps

🧠 Claude Opus решил баг, с которым я боролся почти 5 лет — личная история разработчика C++ и бывшего старший инженер FAANG с 💬 Один из пользователей на Reddit поделился настоящим инсайтом: после многолетней борьбы с трудноуловимым багом, ему наконец-то помог… Claude Opus. Баг был из тех, что появляются раз в полгода, ведут себя нестабильно, и каждый раз ускользают от дебаггера. В отчаянии он просто описал проблему Claude-у — без стеков, логов, трейсинга. И внезапно получил абсолютно точный ответ: баг оказался связан с тем, как обрабатывались замыкания внутри лямбд, теряющих доступ к нужному контексту после асинхронного вызова. 🤯 Результат: 5 лет неуловимого бага ушли за 30 секунд диалога с ИИ. 📌 Это не просто красивая история. Она показывает, как LLM уровня Opus начинает конкурировать не только с поиском и документацией — но и с самим процессом инженерного мышления. 🔍 Что можно вынести: • Не бойся формулировать даже "глупые" вопросы — хорошие модели часто угадывают суть • Застрял на баге? Попробуй объяснить его как человеку — иногда именно это помогает найти решение • Хороший ИИ не заменит опыт, но может стать отличным напарником по отладке 📎 Оригинальный пост на Reddit

🏰 SSHportal — умный шлюз для SSH-доступа без головной боли. Этот проект превращает управление SSH-доступом в интуитивный процесс. Вместо ручного редактирования authorized_keys на каждом сервере, SSHportal централизует контроль через единую точку входа с ролевой моделью доступа. Инструмент имеет встроенную систему инвайтов: можно приглашать пользователей без обмена ключами вручную. Под капотом SQLite/MySQL для хранения данных и полная совместимость с обычными SSH-клиентами. 🤖 GitHub @devopsitsec

☸ История создания Kubernetes — от внутреннего инструмента Google до мировой революции Когда в 2014 году Google выложил в открытый доступ свой внутренний проект под странным именем Kubernetes, мало кто осознал, что это начало настоящей контейнерной революции. Но за этой лаконичной оболочкой скрывалась мощь, проверенная на миллиардах пользователей Google Search, Gmail и YouTube. 🔥 Всё началось с Borg Внутри Google уже с 2003 года существовала система управления контейнерами — Borg. Это был секретный, монструозный и невероятно мощный оркестратор, позволявший запускать сотни тысяч задач на десятках тысяч серверов. Но Borg был закрыт, сложный и не предназначен для внешнего мира. 💡 Факт: Borg умел автоматически лечить упавшие сервисы задолго до того, как "self-healing" стал модным словом в DevOps. 🚀 Почему Kubernetes? Google хотел подарить миру упрощённую, но эффективную версию Borg — с понятным API, без проприетарных завязок и... с хорошим маркетингом. Так родился Kubernetes — проект с открытым исходным кодом, построенный на Go, и вдохновлённый Borg и его экспериментальным "младшим братом" — Omega. 🔷 Факт: Название "Kubernetes" пришло из греческого языка и означает "штурман". Это намёк: Kubernetes управляет "флотом" контейнеров как кораблями. 👨‍💻 Кто стоял у истоков? Изначально за Kubernetes отвечали три инженера Google: Joe Beda Brendan Burns Craig McLuckie Позже к ним присоединился Brian Grant, архитектор Borg, и вскоре десятки инженеров со всего мира стали развивать проект под крылом Cloud Native Computing Foundation (CNCF). 🧨 Факт: Kubernetes стал самым активным проектом на GitHub в 2015 году — больше коммитов, чем у Linux! 🌐 Как Kubernetes завоевал мир? 🔄 Контейнеры стали стандартом благодаря Docker, но их нужно было как-то управлять — и тут вошёл Kubernetes. 🎯 Kubernetes оказался универсальным: он мог запускаться на ноутбуке, в дата-центре, в облаке, даже на Raspberry Pi. 💥 Все большие игроки — AWS, Azure, IBM, Red Hat — вынуждены были поддержать Kubernetes, иначе рисковали остаться вне игры. 📦 Экосистема вокруг Kubernetes выросла в десятки раз: Helm, Istio, Prometheus, ArgoCD, Knative — всё это родилось в его тени. 🛡 Факт: Kubernetes — это не просто оркестратор. Это операционная система для облака. Она изменила сам подход к разработке: теперь приложения проектируются "cloud-native", а не "серверные". ⚙️ Kubernetes сегодня Сейчас Kubernetes: Работает в каждом втором крупном enterprise-проекте Поддерживается всеми облачными провайдерами Является де-факто стандартом для микросервисной архитектуры Вдохновил создание K8s-альтернатив: Nomad, OpenShift, K3s, и других 💡 Вывод Kubernetes — это не просто проект, это движение, начатое с утечки идей из недр Google и переросшее в открытую революцию управления инфраструктурой. Как Git изменил подход к коду, так Kubernetes изменил подход к запуску программ. Сегодня без Kubernetes — ни один серьёзный DevOps не чувствует себя в безопасности. Хочешь больше таких историй из мира технологий? 😉

⚡️ OneUptime — open-source-платформа для мониторинга всего и сразу. Этот инструмент предлагает готовый комплект: от мониторинга uptime до управления инцидентами. Редкий случай, когда open-source-проект не уступает коммерческим аналогам по функционалу. Особенность проекта в глубокой интеграция компонентов. Например, при падении сервиса система автоматически создаёт инцидент, уведомляет ответственных через эскалацию и обновляет статус-страницу. Есть даже встроенный APM с трейсами и метриками производительности. Развернуть можно на Kubernetes или через Docker Compose. 🤖 GitHub @devopsitsec

🚀 Разгоняем kube-prometheus-stack: секретный ингредиент в Observability 🔥 9 июня в 20:00 мск — бесплатный вебинар «Разгоняем kube-prometheus-stack». Мониторинг не должен тормозить, особенно когда что-то идёт не так. Что разберём: – как ускорить отклик Grafana при работе с большими объёмами данных, – что замедляет Prometheus и как с этим бороться, – как сократить сетевой трафик мониторинга без потерь, – как не положить observability-инфру при инциденте, – и какие архитектурные подходы помогают сделать мониторинг отказоустойчивым. Оптимизируйте kube-prometheus-stack и держите руку на пульсе — даже в условиях пиковых нагрузок. 👉 Регистрируйтесь здесь: https://otus.pw/JuU8/?erid=2W5zFGaKsHS Занятие приурочено к старту курса "Observability: мониторинг, логирование, трейсинг", на котором вы научитесь строить эффективные системы мониторинга, работать с Prometheus, Grafana, ELK и другими инструментами, визуализировать метрики. Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🔧 DevOps Pro Tips: Оптимизация контейнеров как у SRE Google Контейнер — это не просто Dockerfile. Это микросистема, и если её не настраивать — она будет жечь CPU, RAM и SSD без пользы. Вот 🔥 продвинутые советы по настройке контейнеров: ⚫ Ограничь права контейнера

docker run --read-only --cap-drop=ALL --security-opt no-new-privileges ...

▪️ --read-only — защищает файловую систему ▪️ --cap-drop=ALL — удаляет лишние привилегии ▪️ no-new-privileges — запрещает повышение прав в процессе ⚫ Установи лимиты CPU и памяти

docker run --memory="512m" --cpus="1.5" ...

▪️ Не давай контейнеру жрать весь хост — особенно на multi-tenant нодах ▪️ Используй cpu-shares, cpuset, ulimits для тонкой настройки ⚫ Чисти от мусора - Используй multi-stage builds — минимизируй размер образа - Оставляй только необходимые бинарники и конфиги - Пример:

FROM golang:1.22 as builder
WORKDIR /app
COPY . .
RUN go build -o app

FROM alpine:3.19
COPY --from=builder /app/app /bin/app
ENTRYPOINT ["/bin/app"]

⚫ Используй distroless или Alpine - Образы типа gcr.io/distroless/static — без шелла, package manager и мусора - alpine — легче, но следи за совместимостью с glibc ⚫ Пропиши healthcheck

HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/health || exit 1

▪️ Kubernetes будет перезапускать только при реальных сбоях ⚫ Подключи observability - Встраивай Prometheus exporter - Логи — в stdout/stderr (для kubectl logs и EFK/PLG стека) - Используй otel, если нужен tracing ⚫ Проверь, чем занят контейнер

docker top <container>
docker inspect --format '{{ .HostConfig }}' <container>

▪️ Вовремя заметишь, если процесс форкает что-то лишнее или идёт через /dev 💡 Эти практики критичны, если: - Вы деплоите в прод с autoscaling - Контейнеры крутятся в k8s или Fargate - Вам важно сократить издержки на ресурсы и повысить безопасность Минимальный, безопасный, ограниченный и наблюдаемый контейнер — залог стабильности продакшна. @devopsitsec

🔧 DevOps Pro Tips: Оптимизация контейнеров как у SRE Google Контейнер — это не просто Dockerfile. Это микросистема, и если её не настраивать — она будет жечь CPU, RAM и SSD без пользы. Вот 🔥 продвинутые советы по настройке контейнеров: ⚫ Ограничь права контейнера

docker run --read-only --cap-drop=ALL --security-opt no-new-privileges ...

▪️ --read-only — защищает файловую систему ▪️ --cap-drop=ALL — удаляет лишние привилегии ▪️ no-new-privileges — запрещает повышение прав в процессе ⚫ Установи лимиты CPU и памяти

docker run --memory="512m" --cpus="1.5" ...

▪️ Не давай контейнеру жрать весь хост — особенно на multi-tenant нодах ▪️ Используй cpu-shares, cpuset, ulimits для тонкой настройки ⚫ Чисти от мусора - Используй multi-stage builds — минимизируй размер образа - Оставляй только необходимые бинарники и конфиги - Пример:

FROM golang:1.22 as builder
WORKDIR /app
COPY . .
RUN go build -o app

FROM alpine:3.19
COPY --from=builder /app/app /bin/app
ENTRYPOINT ["/bin/app"]

⚫ Используй distroless или Alpine - Образы типа gcr.io/distroless/static — без шелла, package manager и мусора - alpine — легче, но следи за совместимостью с glibc ⚫ Пропиши healthcheck

HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/health || exit 1

▪️ Kubernetes будет перезапускать только при реальных сбоях ⚫ Подключи observability - Встраивай Prometheus exporter - Логи — в stdout/stderr (для kubectl logs и EFK/PLG стека) - Используй otel, если нужен tracing ⚫ Проверь, чем занят контейнер

docker top <container>
docker inspect --format '{{ .HostConfig }}' <container>

▪️ Вовремя заметишь, если процесс форкает что-то лишнее или идёт через /dev 💡 Эти практики критичны, если: - Вы деплоите в прод с autoscaling - Контейнеры крутятся в k8s или Fargate - Вам важно сократить издержки на ресурсы и повысить безопасность Минимальный, безопасный, ограниченный и наблюдаемый контейнер — залог стабильности продакшна.

Музыка, бег и летний драйв: что вас ждет на фестивале IT и спорта RUNIT: https://clck.ru/3M6upQ  🥁Хиты любимых групп. Фестиваль RUNIT пройдет 13 июля в Мещерском парке и соберет на одной площадке 10000 человек. Атмосферу драйва со сцены будут задавать «Отпетые мошенники», «Пропаганда», «Краски» и другие звезды. Имя хедлайнера пока в секрете. 🏃Зеленые трассы и классный мерч. Главное событие RUNIT — забег на 3, 5, 10 и 21 км, командный и личный зачет, эстафета и трассы для детей. Бежать будет комфортно — в парке мягкий грунт, много тени и красивые виды. На финише бегуны получат именные медали и футболки от бренда GRI. 🏸 Активности на любой вкус. Для гостей фестиваля будут работать несколько площадок: — спортивная: волейбол, бадминтон, йога, фитнес и т. д; — развлекательная: денди, дженга, мастер-классы и т. д; — фудкорт: еда на выбор и освежающие напитки. Регистрируйтесь на забег по ссылке https://clck.ru/3M6upQ и следите за новостями RUNIT 2025 в телеграм-канале.

🚀 VS Code трансформируется в опенсорнсый ИИ-редактор! Команда Visual Studio Code объявила о планах трансформировать VS Code в редактор с открытым исходным кодом для работы с ИИ. Конкуренция - двигатели прогресса! Где-то напряглась команда Cursor 🤓 🔗 Подробности: aka.ms/open-source-ai-editor #VSCode #OpenSource #ИИ #Разработка #Сообщество

🛠️ Отправка уведомлений Slack из shell-скриптов Автоматизация задач — это здорово, но ещё лучше — знать, когда они завершились или если что-то пошло не так. Slack — популярный мессенджер, поддерживающий ботов, которых можно настроить для автоматических оповещений о важных событиях. Сервер упал? Получите уведомление. Скрипт завершил выполнение? Получите уведомление. Добавив уведомления Slack в свои shell-скрипты, вы можете: - 📣 легко делиться результатами работы скриптов с командой, - 🛡️ быстро реагировать на проблемы, - 🔍 быть в курсе событий без просмотра логов. > Предполагается, что вы уже используете Slack и знакомы с понятием Slack Bot. Также необходимо базовое знание Bash. 🔗 Webhook + curl: секретная связка Slack позволяет использовать входящие Webhook-и для получения сообщений. А curl позволяет отправлять эти сообщения через HTTP POST. Принцип: - Slack даёт вам URL вида https://hooks.slack.com/services/... - Вы используете curl для отправки JSON с текстом сообщения. ⚙️ Как включить входящие Webhook в Slack 1. Зарегистрируйтесь на [api.slack.com/apps](https://api.slack.com/apps) 2. Создайте новое приложение 3. В разделе Incoming Webhooks — активируйте их 4. Добавьте Webhook в рабочее пространство (выберите канал) 5. Сохраните Webhook URL — он понадобится далее 💬 Bash-скрипт для отправки уведомлений Добавьте Webhook в .bashrc:

export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/your/webhook/url"

Пример скрипта мониторинга:

#!/bin/bash

source ~/notify_slack.sh

disk_usage=$(df -h / | awk 'NR==2 {print $5}')
cpu_load=$(uptime | awk -F'load average:' '{ print $2 }' | cut -d',' -f1 | xargs)
hostname=$(hostname)

message="*Отчёт о системе - $hostname*\n* Диск (/): $disk_usage\n* CPU (1 мин): $cpu_load"
notify_slack "$message"

✅ Рекомендации Не хардкодьте токены — используйте переменные окружения Slack ограничивает частоту Webhook-запросов Используйте уведомления только при необходимости (ошибки, алерты и т.п.) Теперь вы можете: - Добавить Slack-уведомления в свои cron-задачи - Отслеживать состояние системы - Получать оповещения об ошибках в скриптах. Подробнее

Можно ли за 4 года стать хорошим фулстек-разработчиком с дипломом престижного вуза, готовым портфолио и сильной теоретической базой? В совместном онлайн-бакалавриате НИУ ВШЭ и Нетологии «Программные системы и автоматизация процессов разработки» готовят как раз таких специалистов. На первых курсах вы изучите базовые математические и гуманитарные предметы, основы программирования и профильные дисциплины по фулстек-разработке. А с третьего курса выберете углублённый трек: руководитель командой разработки или DevOps-инженер. По итогу обучения освоите 4 языка программирования: Java, Python, JavaScript, Go. Вас ждёт сильное студенческое комьюнити, постоянная практика, хакатоны и стажировки. А ещё — все бонусы очной формы обучения: отсрочка от армии, льготы на проезд, доступ к библиотеке, привилегии при посещении театров, льготный кредит на образование. Получите диплом, который поможет строить карьеру в сильных IT-командах. Подробнее Реклама. ООО "Нетология". ИНН 7726464125 Erid 2VSb5xYYjqJ

🌐 Задача-ловушка: Пропавший трафик после настройки iptables Условие: На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок. На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта:

docker run -d -p 8080:80 nginx

❗ Проблема: Снаружи контейнер не доступен. В браузере или curl получаете Connection refused. Но в ss -tlnp порт 8080 виден и слушает. Дополнительно, если выполнить:

curl http://localhost:8080

— сервер отвечает нормально. Но с других машин — нет. ❓ Вопрос: Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему? 🔍 Подсказка: Docker использует nat таблицы и PREROUTING`/`FORWARD цепочки для проброса портов. ✅ Разбор: 💥 Ловушка: Ваш iptables-правила:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через INPUT, но это не так! Когда Docker пробрасывает порт с хоста (например, 8080), схема такая: - Входящий пакет попадает в цепочку PREROUTING (nat) - Потом через FORWARD, если пакет не адресован хосту напрямую, а перенаправлен внутрь контейнера И тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию:

iptables -P FORWARD DROP

Поэтому трафик до контейнера блокируется именно на этапе FORWARD. 🔧 Как проверить: Запустить:

iptables -L -v -n

Вы увидите, что счётчик пакетов в FORWARD показывает дропы. 🛠 Как починить: Добавить правило разрешения проброса пакетов для Docker:

iptables -A FORWARD -o docker0 -j ACCEPT

Или (более строго):

iptables -A FORWARD -i eth0 -o docker0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT

✅ Вывод: • В Linux iptables цепочки работают по строгой логике: - INPUT — для пакетов к хосту - FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы) • Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через FORWARD, а не напрямую через INPUT. 💡 Бонус-вопрос: Что изменится, если вы запустите контейнер с флагом --network=host? Какие цепочки будут задействованы тогда?

🦙 RamaLama — контейнерный подход к работе с AI-моделями. Этот инструмент переносит логику Docker/Podman в мир искусственного интеллекта, позволяя запускать LLM-модели как контейнеры с автоматической подгрузкой оптимизированных образов под ваше железо. Вместо ручной настройки зависимостей RamaLama сама определяет доступные GPU/CPU и разворачивает изолированную среду для инференса. Модели из HuggingFace, Ollama или OCI-регистров можно тестировать через REST API или чат-интерфейс, не опасаясь утечек данных — все запуски происходят без сети с удалением временных файлов. 🤖 GitHub @devopsitsec

Знание контейнеров: путь к большим деньгам в ИТ или временный хайп? 💰 19 мая (понедельник) в 18:00 присоединяйтесь к настоящему батлу мнений. В прямом эфире разработчики контейнерной платформы «Штурвал» вместе с AM Live соберут тех, кто знает индустрию изнутри. Топовые спикеры обсудят, действительно ли знание Docker и Kubernetes в приоритете нужных навыков или это проходящая мода, которая никак не влияет на успешный карьерный трек? Основные вопросы дискуссии: ▪️Насколько знания контейнеризации повышают конкурентоспособность и стоимость специалиста на рынке? ▪️Кто сейчас нужен больше — IT-специалист или IT generalist? ▪️Опыт работы с «ванильным» K8s VS с коммерческой платформой: есть ли разница? ▪️Что делать, если Kubernetes вообще не нравится? ▪️Площадки для обучения контейнеризации: норм или стрем? 🔜 Регистрация

🧠 DevOps-задача: "Контейнер Шрёдингера" Условие: Ты получаешь баг-репорт: > "Приложение внутри Docker-контейнера после деплоя не работает, но docker exec показывает, что оно запущено, порт слушает, ошибок нет. Однако при curl изнутри — всё работает, а снаружи — нет ответа." Что известно: - Docker-контейнер на основе alpine:3.18 - Приложение запускается через CMD ["/bin/service-start"] - Порт 8080 проброшен (`-p 8080:8080`) - curl localhost:8080 внутри контейнера возвращает 200 OK - curl localhost:8080 на хосте — зависает - netstat -tulpn показывает, что порт 8080 прослушивается внутри Задача: Найди вероятную причину, предложи способ воспроизведения, диагностики и исправления. Подумай как DevOps, а не просто как админ. 📌 Разбор: 🕵️ Подвох №1: **приложение слушает 127.0.0.1:8080**, а не 0.0.0.0 • внутри `curl localhost:8080` работает • а хост не может достучаться, потому что `127.0.0.1` — это loopback внутри контейнера, а не на host Решение: - Проверить снаружи: `docker inspect <container_id> | grep IPAddress` - Проверить bind-порт внутри: ```bash netstat -tulpn | grep 8080 # или ss -tulpn | grep 8080 ``` - Если видим `127.0.0.1:8080` — всё ясно: нужно слушать на `0.0.0.0:8080` 🛠 Исправление: 1. Проверь запуск приложения. Может, внутри у тебя: ```bash python3 app.py ``` и он слушает только на localhost? Добавь: ```bash python3 app.py --host=0.0.0.0 ``` 2. В Go, Node.js, Python и т.д. — по умолчанию bind'ят на 127.0.0.1 Проверь в настройках приложения или командной строке 🎯 Что проверяет задача: • Умение мыслить в терминах изоляции контейнеров • Понимание сетевых пространств имён (network namespaces) • Знание, как работает NAT между контейнером и хостом • Умение диагностировать "невидимый" bind • Привычку **проверять всё снаружи**, а не только внутри контейнера Подобные ошибки легко пропустить, особенно если всё проверяешь изнутри контейнера.

На пути к 9999: практики обработки и мониторинга инцидентов Каждый продукт Яндекс 360 (Диск, Почта, Телемост и другие) состоит из десятков, а то и сотен микросервисов, и каждый из них должен стабильно работать 24/7/365 и соответствовать самым высоким требованиям надёжности. Игорь Обручев, руководитель группы SRE в Яндекс 360, рассказал, какими принципами они руководствуются, когда делают сервисы, как без паники чинят инциденты. А также кратко об учениях и для чего они нужны. В докладе — про всё это, а также про команду 9999, тиры надёжности и про то, за что отвечает синий цвет протокола. Больше материалов о технологиях в Яндекс 360 @yandex360team

⚡️ Kubernetes устраняет проблему безопасности с приватными образами, которую не решали более 10 лет Ранее, при использовании политики imagePullPolicy: IfNotPresent, kubelet мог запускать контейнеры из приватных образов, даже если pod не передавал нужные imagePullSecrets. Это означало, что уже загруженные образы могли использоваться без повторной проверки прав доступа. Начиная с Kubernetes v1.33, kubelet теперь проверяет учетные данные pod-а даже для локально кэшированных образов. Если образ найден на узле, kubelet удостоверяется, что pod имеет соответствующие pull credentials, прежде чем разрешить его запуск. Ожидается, что в v1.34 эта функция перейдёт в бета-стадию и получит дополнительные улучшения. https://kubernetes.io/blog/2025/05/12/kubernetes-v1-33-ensure-secret-pulled-images-alpha/

Вы CTO или хотите им стать? Управление качеством — это не просто исправление ошибок. Это предотвращение проблем до их появления. На нашем бесплатном вебинаре мы расскажем, как именно CTO может проактивно управлять качеством в своих проектах и минимизировать риски. 🔑 Что узнаете на вебинаре: · Как выявлять риски до внедрения, а не после провала · Инструменты превентивного анализа: тест-дизайн, Code Review, метрики и автоматизация · Почему ответственность за качество лежит не только на тестировщиках, а на всей команде 🚀 Кому будет полезно: CTO, руководителям разработки, QA-лидам и тех-менеджерам, которые хотят выстроить эффективную систему контроля качества и избежать ошибок на ранних этапах. 🎓 Понравится вебинар - приходите на курс «CTO / Технический директор» со скидкой по промокоду BIRDS_CTO. 🔗 Зарегистрироваться на вебинар: https://otus.pw/83wz/?erid=2W5zFGAjnd6 Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

📜 История SQL — от лабораторной идеи до «языка данных» № 1 Как появился самый известный язык работы с базами, почему он едва не остался «Сиквелом» и какие любопытные факты о нём редко всплывают в учебниках. 1. Всё началось с таблицы на бумаге - 1970 г. — британский математик Эдгар Ф. Кодд публикует культовую статью *“A Relational Model of Data for Large Shared Data Banks”*. - В ней впервые прозвучала идея: хранить данные в виде связанных таблиц, а не как запутанные иерархии (IMS) или сетевые графы (Codasyl). - Коллеги в IBM скептически называли это «бумагой на буквы», но разрешили сделать прототип, чтобы проверить утопию Кодда на практике. 2. SEQUEL — «английский» запрос к таблицам - 1973–1974 гг. — в лаборатории IBM San José (ныне Almaden) двое молодых исследователей, Дональд Чемберлин и Рэймонд Бойс, берутся за проект System R. - Чтобы обращаться к реляционным таблицам, они придумывают Structured English QUEry Language — SEQUEL. - Ключевая фишка — запросы выглядят почти как английские предложения:

    SELECT name, salary
      FROM employees
     WHERE dept = 'R&D';
    

- В 1974‑м публикуют первую спецификацию; академики критикуют за «слишком поверхностный английский», но программисты в восторге. 3. Почему SEQUEL стал SQL - Торговая марка “SEQUEL” уже принадлежала авиастроительной компании *Hawker Siddeley*. - IBM, опасаясь суда, в 1976 г. официально отказывается от «E» и оставляет SQL (Structured Query Language). - *Небольшая путаница осталась навсегда: кто‑то произносит «эс‑кью‑эл», кто‑то — «сиквел».* 4. Коммерческий взлёт - 1978 | Первая демонстрация System R внутри IBM | показала, что SQL работает быстрее ожиданий | - 1979 | Стартап Relational Software (позже Oracle**) выпускает **Oracle V2 — первый коммерческий SQL‑движок | IBM ещё не успела выйти на рынок - 1981 | IBM выпускает SQL/DS для мейнфреймов | стандарт де‑факто закрепляется - 1983 | Дебют DB2 — теперь SQL есть почти в каждом крупном банке 5. Стандартизация и эволюция - ANSI SQL‑86 → SQL‑92 (появился `JOIN ... ON`) → SQL:1999 (рекурсия, триггеры) → SQL:2003 (XML) → … → SQL:2023 (JSON, property graphs). - Каждые 3–5 лет комитет добавляет «модные» возможности, но 90 % повседневных запросов всё ещё укладываются в синтаксис 1980‑х. 6. Забавные факты, которые украсят small talk 🍸 1. NULL ≠ 0 и NULL ≠ NULL — «неизвестное значение» нарушает законы логики, за что его зовут *“пятой ногой”* реляционной алгебры. 2. `SELECT *` — наследие печати на станке. Звёздочка означала «все колонки», чтобы не писать их руками в 132‑символьных перфокартах. 3. Команда `GO` в MS SQL Server не принадлежит стандарту SQL — это директива из старого клиента isql. 4. В Oracle долго не было `LIMIT`, а в MySQL — `RIGHT JOIN`. Поэтому админы шутили: «истинный межплатформенный SQL — это `SELECT 1;`». 5. Первый SQL‑вирус — червь *Slammer* (2003) — парализовал интернет за 10 минут через уязвимость в SQL Server 2000. 6. SQL — декларативный язык, но внутри СУБД каждый SELECT превращается в процедурный план. 7. `DROP DATABASE` придумали позже, чем `CREATE`. Сначала удалять целую БД казалось слишком опасным. 7. Почему SQL живёт дольше модных NoSQL‑наследников - Математическая база. Таблицы + операции Кодда образуют алгебру с предсказуемой оптимизацией. - Стандарты и переносимость. Код двадцатилетней давности можно запустить в современной Postgres или MariaDB. - Большая экосистема. От Excel‑плагинов до BigQuery — везде так или иначе поддерживается SQL‑диалект. - Сопротивляемость моде. Каждый «убийца SQL» (MapReduce, GraphQL, документные БД) в итоге добавляет свой адаптер SELECT …. Итог: SQL родился как эксперимент IBM, пережил смену названий и юридические баталии, но в итоге стал «лентой Мёбиуса» мира данных: можно зайти с любой стороны — и всё равно окажешься в FROM. https://www.youtube.com/shorts/EuFjzuVHkHE