Happy Devops — сообщество адекватных инженеров

Есть работа!

Друзья, я ищу в одну из своих команд крутого тимлида, который возглавит команду разработки.

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

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

Рутина? Ну камон, ее нет как факта, каждый день — это новый вызов. Маркетплейс, инфраструктура ПВЗ, банк, тревел, фреш и еще куча всего — они все живут на нашей платформе

Это high-severity сервисы, наш etcd предоставляет конфигурации для более чем 5000 микросервисов и failure is not an option, мы не можем позволить себе валяться, будет очень больно

Мы форкнули Vault, потому что ванильный уже не подходит. Мы форкнули один из кусочков etcd и готовимся форкнуть его весь, потому что на наших нагрузках и требованиях ванильный не справляется. Мы разрабатываем свой etcd-operator для k8s, который позволит крутить etcd на огромном федеративном кластере Kubernetes, в нескольких ЦОДах и с сотнями тысяч деплойментов. Мы пишем низкоуровневые плагины для k8s на уровне common interfaces, чтобы обеспечить отказоустойчивость наших решений.

Мы растем кратно год от года и то, что сработало в high-season в прошлом году, в следующем уже будет дремучим легаси

Я гарантирую максимально интересные задачи, работу плечом к плечу с лучшими из индустрии и гордость за результат своего труда.

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

Если вы давно хотели поработать со мной, то вот отличный шанс. Приходите сами или перешлите вакансию знакомому лиду😊

Почитать подробное описание и откликнуться можно на сайте Озона или через меня. Готов ответить на любые ваши вопросы (кроме тех, которые под NDA🙃)

〰️〰️〰️〰️〰️〰️〰️
🗞 @boombah_in_da_house

Observability — это не просто модное слово. Вот реальный пример: платежный сервис внезапно стал отдавать 500-ки. Без правильно настроенной системы наблюдения придется потратить часы на поиск причины.

RED метрики (Rate, Errors, Duration) в Prometheus сразу покажут масштаб бедствия: какой процент запросов падает, как растет латенси, сколько пользователей под ударом. Базовый дашборд в Grafana для каждого сервиса — три панели с RED метриками и алерты при отклонении от нормы.

Distributed tracing через Jaeger раскроет полную картину. Один платёжный запрос проходит через auth-сервис (50мс), потом биллинг (200мс), и где-то между ними теряется. Раньше такой дебаг занимал часы, с трейсами — минуты.

Structured logging решает проблему поиска. JSON-логи с метаданными в Loki позволяют мгновенно найти все события по конкретному requestId или userId. Один запрос в LogQL: {job="payment-service"} |= "error" | json | user_id=123456 — и вот она, причина сбоя.

А теперь про SLO — тут начинается самое интересное. Типичная ошибка — взять с потолка цифры типа "99.9% успешных запросов". Звучит красиво, но это путь в никуда. SLO должны отражать реальный пользовательский опыт. Если юзер не заметит падения успешности до 95% — зачем держать планку на 99.9%?

Ещё один подводный камень — измерение не тех метрик. Классика жанра: латенси базы данных 99.999%, а пользователи жалуются на тормоза. Оказывается, замеряли только время выполнения запроса, забыв про очередь коннектов к БД. История из жизни: один сервис гордился своими SLO по доступности, пока не выяснилось, что health-check проверял только живость процесса, а не работоспособность бизнес-логики.

Правильные SLO рождаются из боли. Сначала инциденты, потом анализ их влияния на бизнес, и только потом — осмысленные цифры. Метрики, логи и трейсы помогают превратить этот опыт в конкретные показатели. И да, их придется регулярно пересматривать — бизнес не стоит на месте.

🏴‍☠️ @happy_devops

Коллеги, праздники прошли и мы снова на связи! Команда HappyDevops поздравляет вас с Новым годом, мы желаем вам пять девяток в аптайме, замечательных задач, новых вызовов и отщывчивых систем! Учитесь, растите и развивайтесь. Мы традиционно начинаем новую неделю и наша тема — мониторинг!

Мониторинг трансформируется? На смену старой доброй связке RRD и Nagios пришло понятие observability, и она перевернула представление о том, как отслеживать здоровье систем.

За последние пять лет инфраструктура выросла из детских штанишек. Микросервисы, контейнеры, serverless — всё это сделало классический мониторинг бесполезным. Нет смысла просто проверять CPU, память и диск. В распределённых системах баги живут на стыках сервисов, а корень проблем прячется в недрах асинхронного взаимодействия.

Observability строится на трёх китах: метрики, логи и трейсы. Метрики показывают общую картину, логи рассказывают что случилось, а трейсы объясняют почему. И если мониторинг отвечал на вопрос "что сломалось?", то observability даёт ответ на "почему это случилось?".

SLO (Service Level Objectives) стали новой валютой надёжности. Вместо бинарного "работает/не работает" появились чёткие метрики успеха. 99.9% запросов должны выполняться быстрее 200мс? Отлично, настройка алертов и отслеживание трендов решают эту задачу. Никакой магии — только точные цифры и понятные цели.

В современном мире недостаточно знать, что сервис упал. Критично предвидеть проблемы до того, как они затронут пользователей. Observability становится третьим глазом инженера, позволяя заглянуть в самое сердце системы.

На этой неделе разговор пойдет о каждом аспекте observability. От базовой настройки Prometheus до продвинутых техник трейсинга в Jaeger. Материал будет глубоким и детальным — держите свои дашборды наготове.

🏴‍☠️ @happy_devops

IaC Week: уроки управления большой инфраструктурой

Масштабные проекты в Terraform раскрывают истинную сложность управления инфраструктурой. Недостаточно просто писать код — нужна целая система практик и процессов. Опыт реальных проектов показывает несколько критических моментов.

Первый — изоляция компонентов через отдельные state-файлы. База данных живет отдельно от сети, сеть — отдельно от вычислительных ресурсов. Это не только упрощает откат изменений, но и защищает от каскадных сбоев при обновлениях.

Второй — строгая система версионирования. Каждый модуль получает свой тег по semver, каждое изменение проходит через пайплайн с тестами. State-файлы хранятся в Object Storage с версионированием и репликацией между регионами.

Третий — автоматизация всех рутинных операций. План изменений формируется автоматически, проверяется линтером и security-сканером, а после ревью деплоится в production без ручных действий. Человеческий фактор исключен везде, где это возможно.

В итоге все сводится к базовому принципу: инфраструктурный код должен быть таким же надежным и поддерживаемым, как прикладной. Только тогда можно говорить о настоящем Infrastructure as Code.

🏴‍☠️ @happy_devops

Best practices для масштабных проектов: принципы здоровой инфраструктуры

Успешные инфраструктурные проекты строятся не на конкретных технологиях, а на фундаментальных принципах. Масштабные системы требуют особого внимания к деталям и проверенных практик, которые помогают держать сложность под контролем. Стабильность таких систем обеспечивается сочетанием архитектурных решений, процессов и инструментов.

Структура проекта начинается с четкой организации кода. Монорепозиторий с модулями разделяется на слои по уровню абстракции, что упрощает навигацию и поддержку:

infrastructure/
├── modules/           # Переиспользуемые модули
│   ├── network/      # Базовая сетевая инфраструктура
│   ├── compute/      # Compute ресурсы
│   └── storage/      # Хранилища данных
├── environments/      # Окружения
│   ├── prod/         # Production
│   └── stage/        # Staging
└── platform/         # Платформенные сервисы
    ├── monitoring/   # Мониторинг
    └── security/     # Безопасность

Каждый модуль проходит через строгий процесс тестирования. Unit-тесты проверяют корректность отдельных компонентов, интеграционные — взаимодействие между ними. Автоматизированные тесты запускаются при каждом изменении:

module "test_network" {
  source = "../../modules/network"

  providers = {
    yandex = yandex.testing
  }

  environment = "test"
  subnets = {
    "a" = ["10.0.1.0/24"]
    "b" = ["10.0.2.0/24"]
    "c" = ["10.0.3.0/24"]
  }
}

resource "test_assertions" "network" {
  component = "network"

  check "subnets_created" {
    description = "Проверка создания подсетей"
    condition   = length(module.test_network.subnet_ids) == 3
  }

  check "network_connectivity" {
    description = "Проверка связности подсетей"
    condition   = can(module.test_network.test_connectivity)
  }
}

Для крупных проектов критична система ограничений и политик. Terraform Sentinel защищает от нарушения корпоративных стандартов и автоматически блокирует небезопасные изменения:

policy "enforce_mandatory_tags" {
  enforcement_level = "hard-mandatory"
  
  rule "check_tags" {
    source = "./rules/tags.sentinel"
  }
}

import "tfplan/v2" as tfplan

mandatory_tags = ["project", "environment", "owner", "cost-center"]

check_resource_tags = func(resource) {
    tags = resource.change.after.labels
    return all mandatory_tags as tag {
        tags contains tag
    }
}

Отдельный акцент делается на мониторинг и наблюдаемость. Каждое изменение инфраструктуры должно оставлять след в системе. Метрики, логи и алерты формируют полную картину состояния инфраструктуры:

resource "yandex_monitoring_dashboard" "terraform" {
  name = "terraform-changes"
  
  chart {
    title = "Infrastructure Changes"
    
    metrics {
      name = "terraform.apply.success"
      aggregation = "COUNT"
    }
    
    metrics {
      name = "terraform.apply.failure"
      aggregation = "COUNT"
    }
  }

  alert {
    name = "High Rate of Failed Changes"
    condition = "rate(terraform.apply.failure[1h]) > 3"
    severity = "critical"
  }
}

🏴‍☠️ @happy_devops

Автоматизация развертывания: Пайплайны Terraform без компромиссов

Когда инфраструктурой занимается команда, ручной запуск terraform apply превращается в потенциальную катастрофу. Даже небольшая ошибка может привести к непредсказуемым последствиям, особенно в масштабных проектах. Полноценный CI/CD для инфраструктурного кода становится не просто удобством, а необходимостью. Автоматизация пайплайнов снижает риск человеческого фактора, ускоряет развертывание и обеспечивает прозрачность процессов.

Структура базового пайплайна

Типичный пайплайн для Terraform включает четыре ключевых этапа:
1. Линтинг — проверка стиля и выявление ошибок в коде.
2. Валидация — гарантирует, что конфигурация корректна и соответствует стандартам безопасности.
3. Планирование изменений — создаёт план, который можно проверить перед применением.
4. Применение — финальный этап, на котором изменения внедряются в инфраструктуру.

Пример базового пайплайна на GitLab CI:

variables:
  TF_ROOT: ${CI_PROJECT_DIR}/terraform
  TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state

stages:
  - validate
  - plan
  - apply

fmt:
  stage: validate
  script:
    - cd ${TF_ROOT}
    - terraform fmt -check -recursive
    - tflint --config=.tflint.hcl

validate:
  stage: validate
  script:
    - cd ${TF_ROOT}
    - terraform init
    - terraform validate
    - checkov -d . --framework terraform

Двухступенчатый процесс для безопасности

Для минимизации рисков используется двухступенчатый процесс:
1. Планирование: план изменений публикуется в Merge Request для ревью.
2. Применение: изменения внедряются только после проверки и подтверждения.

plan:
  stage: plan
  script:
    - cd ${TF_ROOT}
    - terraform plan -out=plan.tfplan
  artifacts:
    paths:
      - ${TF_ROOT}/plan.tfplan
    expire_in: 1 week

apply:
  stage: apply
  script:
    - cd ${TF_ROOT}
    - terraform apply plan.tfplan
  dependencies:
    - plan
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

Защита секретов и управление доступом

Безопасность — ключевой аспект. Секреты передаются через защищённые переменные CI/CD, а временные credentials с ограниченным сроком действия предотвращают компрометацию:

before_script:
  - vault kv get -field=YC_TOKEN secret/terraform > token.json
  - export YC_TOKEN=$(cat token.json)
  - vault token revoke -self

after_script:
  - rm -f token.json
  - unset YC_TOKEN

Расширение пайплайна: от документации до тестирования

Чтобы обеспечить максимальную надёжность, пайплайн можно дополнить:
🔘 Автоматической генерацией документации с помощью terraform-docs, чтобы новые разработчики быстрее понимали структуру.
🔘Проверкой security best practices через tfsec, что помогает выявить уязвимости ещё на этапе разработки.
🔘Постдеплойными тестами, например проверкой доступности сервисов или соответствия стандартам:

tests:
  stage: test
  script:
    - cd ${TF_ROOT}/tests
    - go test -v ./...
    - inspec exec compliance -t yc://
  dependencies:
    - apply
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Идемпотентность как основа надёжности

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

Автоматизация развертывания с помощью CI/CD для Terraform — это инвестиция в стабильность, безопасность и эффективность вашей инфраструктуры. Пайплайны, построенные по принципу идемпотентности и безопасности, помогают не только сократить время на рутинные задачи, но и минимизировать риски.

🏴‍☠️ @happy_devops

Управление состоянием в Terraform: разделяй и властвуй ⚡️

Состояние инфраструктуры в больших проектах становится узким местом при масштабировании команд и сервисов. Remote state решает проблемы с блокировками и конкурентным доступом, но требует продуманной структуры. Главный принцип — разделение state-файлов по четким границам ответственности.

В основе грамотного управления состоянием лежит принцип разделения state-файлов по логическим границам. Каждый state-файл описывает независимый компонент инфраструктуры. Такой подход уменьшает риск конфликтов при параллельной работе нескольких команд:

# network/main.tf
terraform {
  backend "s3" {
    bucket   = "terraform-states"
    key      = "network/terraform.tfstate"
    endpoint = "storage.yandexcloud.net"
  }
}

# databases/main.tf
terraform {
  backend "s3" {
    bucket   = "terraform-states"
    key      = "databases/terraform.tfstate"
    endpoint = "storage.yandexcloud.net"
  }
}

Для обмена данными между состояниями используется data source terraform_remote_state. Сетевые настройки из одного state становятся доступны другим компонентам. Это позволяет избежать жесткой связанности между модулями и упрощает поддержку кода:

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket   = "terraform-states"
    key      = "network/terraform.tfstate"
    endpoint = "storage.yandexcloud.net"
  }
}

resource "yandex_mdb_postgresql_cluster" "postgres" {
  name        = "prod-postgres"
  environment = "PRODUCTION"
  network_id  = data.terraform_remote_state.network.outputs.network_id

  config {
    version = "15"
    resources {
      resource_preset_id = "s3-c2-m8"
      disk_size         = 100
    }
  }
}

При работе с секретами state-файл шифруется на уровне Object Storage через KMS. Ключ доступа выдается только членам инфраструктурной команды. Дополнительный уровень защиты обеспечивает audit log всех операций с state-файлом:

terraform {
  backend "s3" {
    bucket     = "terraform-states"
    key        = "secrets/terraform.tfstate"
    endpoint   = "storage.yandexcloud.net"
    kms_key_id = "abjhq8c9gct5pd5klm7p"
    
    access_key = var.storage_access_key
    secret_key = var.storage_secret_key
  }
}

Отдельное внимание стоит уделить резервному копированию state-файлов. Настройка репликации бакетов между регионами защищает от потери данных при отказе основного региона. А регулярные бэкапы позволяют восстановить состояние на любой момент времени.

🏴‍☠️ @happy_devops

Версионирование инфраструктуры: практики безопасных изменений 📦

Современная инфраструктура требует продуманного подхода к версионированию. Неконтролируемые изменения в Terraform приводят к простоям сервисов и потере данных. Правильно выстроенное версионирование позволяет избежать этих проблем.

Базовый уровень версионирования — git-тэги для каждого модуля с семантическим версионированием. Мажорная версия растет при несовместимых изменениях, минорная — при добавлении фич, патч — при исправлении ошибок:

module "web_cluster" {
  source = "git::https://github.com/company/tf-modules.git//web-cluster?ref=v2.3.1"
  
  cluster_name = "prod-web"
  instance_count = 5
  zone_id = "Z2FDTNDATAQYW2"
}

История изменений state-файла хранится с помощью версионирования S3. По умолчанию Terraform сохраняет только последнюю версию, поэтому версионирование включается на уровне бакета с правилами очистки старых версий:

resource "aws_s3_bucket" "terraform_state" {
  bucket = "company-terraform-state"

  versioning {
    enabled = true
  }

  lifecycle_rule {
    enabled = true
    noncurrent_version_expiration {
      days = 90
    }
    abort_incomplete_multipart_upload_days = 7
  }
}

Отдельные ветки для каждого окружения с изолированными pipeline'ами позволяют тестировать изменения безопасно. Новые версии модулей проходят проверку в staging перед деплоем в production. При обнаружении проблем revert коммита автоматически возвращает предыдущую версию через CI/CD.

Критичные изменения требуют blue-green deployment. Новая инфраструктура разворачивается параллельно с действующей, трафик переключается постепенно. В случае проблем быстрый откат происходит через DNS:

resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "www.example.com"
  type    = "A"

  alias {
    name                   = var.environment == "blue" ? aws_lb.blue.dns_name : aws_lb.green.dns_name
    zone_id                = var.environment == "blue" ? aws_lb.blue.zone_id : aws_lb.green.zone_id
    evaluate_target_health = true
  }
}

🏴‍☠️ @happy_devops

IaC Week: Управляем инфраструктурным кодом как профессионалы

Эта неделя посвящена полной перезагрузке подходов к Infrastructure as Code (IaC). Мы разберём, как эффективно версионировать инфраструктуру, управлять состоянием, автоматизировать развертывание и внедрять лучшие практики для масштабных проектов. А начнём с главного вызова — как держать Terraform под контролем, когда проект разрастается до гигантских масштабов.

Когда инфраструктурный код выходит из-под контроля

Крупные проекты неизбежно сталкиваются с проблемой масштабирования инфраструктурного кода. В одном из наших кейсов код вырос до 50 тысяч строк. Это быстро привело к проблемам: потере структуры, сложностям в управлении и росту риска ошибок. Решение пришло через переосмысление подходов к управлению инфраструктурой.

Workspace'ы: отказ от копирования конфигураций

Первым шагом стало использование workspace'ов для изоляции окружений. Вместо устаревшего копирования terraform.tfvars мы перенесли все переменные в код. Такой подход упрощает управление и снижает вероятность ошибок:

workspace_config = {
  production = {
    instance_type    = "t3.large"
    min_size         = 3
    max_size         = 10
    environment      = "prod"
    backup_retention = 30
  }
  staging = {
    instance_type    = "t3.small"
    min_size         = 1
    max_size         = 3
    environment      = "stage"
    backup_retention = 7
  }
}

locals {
  config = workspace_config[terraform.workspace]
}

Теперь изменения для каждого окружения четко определены, а переключение между ними стало безопасным и простым.

Надёжное хранение состояния

Для хранения state-файлов мы выбрали S3 с включённым версионированием и блокировками через DynamoDB. Это предотвращает одновременное изменение state и защищает данные от случайных повреждений. Более того, мы добавили репликацию бакета в другой регион, чтобы обезопасить инфраструктуру даже в случае полного сбоя одного из регионов AWS:

terraform {
  backend "s3" {
    bucket         = "terraform-state-company"
    key            = "infrastructure/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
    versioning     = true
    replication_configuration {
      role = "arn:aws:iam::123456789012:role/service-role/s3-bucket-replication"
      rules {
        status = "Enabled"
        destination {
          bucket = "arn:aws:s3:::terraform-state-backup"
          region = "eu-central-1"
        }
      }
    }
  }
}

Этот подход обеспечил безопасность и восстановление инфраструктуры в любых непредвиденных обстоятельствах.

Модули и автоматизация: простота в управлении

Чтобы упорядочить код, мы приняли стратегию: "один сервис — один модуль". Все повторяющиеся компоненты вынесли в переиспользуемые модули. Это значительно упростило поддержку и добавление новых фич.

Для автоматизации развертывания мы внедрили CI/CD pipeline:
🔘 Форматирование и линтинг: проверка стиля кода.
🔘 Проверка плана изменений: гарантируем, что никакие изменения не попадают в production случайно.
🔘 Документация: с помощью terraform-docs мы автоматически генерируем документацию, что помогает новым разработчикам быстро вникнуть в проект.

Infrastructure as Code — это не просто способ автоматизации, это мощный инструмент управления инфраструктурой. Использование workspace'ов, надёжного хранения состояния, продуманной модульности и автоматизации делает инфраструктурный код масштабируемым, понятным и устойчивым.

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

🏴‍☠️ @happy_devops

Отказоустойчивость базы данных проверяется не в момент настройки репликации, а в момент аварии. И часто в самый неподходящий момент — посреди ночи или во время пиковой нагрузки. Поделюсь реальными историями и разбором полетов.

Типичный сценарий: праздничная распродажа, нагрузка на пике, и тут primary-база падает. Автоматический failover звучит заманчиво, но реальность сложнее. В одном проекте автофейловер сработал при кратковременном сетевом сбое, поднял новый primary, а когда связь восстановилась — в системе оказалось два мастера. Итог: split-brain и потерянные транзакции.

Теперь в критичных системах используем ручной failover с Patroni. Конфигурация выглядит так:

scope: postgres-cluster
namespace: /db/
name: postgres1

restapi:
  listen: 0.0.0.0:8008
  connect_address: 10.0.0.1:8008

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 10.0.0.1:5432
  data_dir: /data/postgres
  bin_dir: /usr/lib/postgresql/14/bin

  parameters:
    max_connections: 100
    shared_buffers: 4GB
    wal_level: replica
    hot_standby: "on"

Каскадная репликация помогает снизить нагрузку на primary. Вместо десяти реплик, висящих на мастере, строим дерево: пара реплик первого уровня раздает WAL остальным. В PostgreSQL это настраивается через primary_conninfo:

-- На реплике первого уровня
primary_conninfo = 'host=10.0.0.1 port=5432'

-- На реплике второго уровня
primary_conninfo = 'host=10.0.0.2 port=5432'

Географически распределенные системы добавляют веселья. Латенция между дата-центрами может достигать сотен миллисекунд. Синхронная репликация в таких условиях убивает производительность. На практике работает схема с локальным кластером в каждом регионе и асинхронной репликацией между регионами.

Мониторинг репликации — отдельное искусство. Следим за метриками через Prometheus:

- job_name: 'postgres_exporter'
  static_configs:
    - targets: ['10.0.0.1:9187']
  metrics_path: /metrics
  params:
    query:
      - 'pg_replication_lag'
      - 'pg_wal_activity'

И обязательно тестируем failover. Регулярно. По графику. С записью времени переключения и подробным разбором каждого случая. Только так можно быть готовым к реальной аварии.

Из последних кейсов: база на 12TB с репликацией между континентами. Переключение на другой континент занимало 40 минут. Ускорили до 5 минут через комбинацию логической и физической репликации: основные таблицы реплицировали физически, а небольшие справочники — логически.

🏴‍☠️ @happy_devops

Репликация данных — основа отказоустойчивости в современных системах. База данных без реплик похожа на сервер без бэкапов: всё работает отлично, пока не случится катастрофа. А потом становится поздно.

Primary-Secondary архитектура — самый распространённый подход. Primary принимает все изменения и пересылает их на реплики. Secondary работают на чтение и готовы подхватить нагрузку при отказе мастера. Звучит просто, но дьявол в деталях.

Синхронная репликация гарантирует, что данные попали на реплику до подтверждения записи. Транзакция не завершится, пока secondary не ответит "данные у меня". Надёжно, но медленно — каждая запись ждёт ответа от реплики. В PostgreSQL это выглядит так:

ALTER SYSTEM SET synchronous_commit TO 'on';
ALTER SYSTEM SET synchronous_standby_names TO 'replica1';

Асинхронная репликация работает в фоне. Primary подтверждает транзакцию сразу, а secondary догоняют когда смогут. Быстро, но есть риск потери данных при падении мастера. MongoDB по умолчанию использует асинхронную репликацию:

{w: 1, j: true} // Ждём запись только на primary
{w: 'majority', j: true} // Ждём запись на большинство нод

Multi-master репликация позволяет писать в любую ноду кластера. Звучит заманчиво, но порождает проблему конфликтов. Две ноды могут одновременно изменить одни и те же данные. Галера-кластер для MySQL решает это через сертификацию транзакций — узлы договариваются о порядке изменений.

Отставание реплик — главная метрика здоровья репликации. В PostgreSQL следим за lag в pg_stat_replication, в MongoDB — за replication lag в rs.status(). Если реплика отстает больше определенного порога — пора разбираться в причинах.

Мониторинг критичен. Нужно следить не только за отставанием, но и за статусом WAL (Write Ahead Log) архивов, свободным местом на дисках реплик и состоянием сетевого соединения между узлами. Один пропущенный WAL сегмент — и придется переинициализировать реплику с нуля.

А еще репликация требует внимательной работы с транзакциями. Длинные транзакции на primary мешают очистке WAL, а значит, растет нагрузка на диск и сеть. И секционированные таблицы тоже могут преподнести сюрприз — операции с партициями должны реплицироваться атомарно.

🏴‍☠️ @happy_devops

Переход на партиционированные таблицы в боевой системе похож на замену колес на едущей машине. Один неверный шаг — и вся система встанет. Разберем, как провести миграцию безопасно и что делать с гигантскими объемами данных.

Вот реальный кейс из практики. Таблица с данными о транзакциях весила 4 ТБ и росла на 50 ГБ в день. Запросы за последний месяц работали быстро благодаря индексам, но исторические отчеты могли считаться часами. Решение — партиционирование по месяцам.

Первый шаг — создание структуры:

CREATE TABLE transactions_new (
    id bigint,
    created_at timestamp,
    amount decimal,
    -- другие поля
) PARTITION BY RANGE (created_at);

-- Создаем партиции для каждого месяца
CREATE TABLE transactions_2024_01 
PARTITION OF transactions_new 
FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');

Дальше начинается самое сложное — перенос данных. Прямой INSERT SELECT на таких объемах заблокирует таблицу на часы. Правильный путь — батчинг с параллельной обработкой:

-- Функция для переноса данных за один день
CREATE OR REPLACE FUNCTION migrate_day(day_start date) 
RETURNS integer AS $$
BEGIN
    RETURN WITH moved AS (
        DELETE FROM transactions 
        WHERE created_at >= day_start 
        AND created_at < day_start + interval '1 day'
        RETURNING *
    )
    INSERT INTO transactions_new 
    SELECT * FROM moved;
END;
$$ LANGUAGE plpgsql;

-- Запускаем параллельно для разных дней
SELECT migrate_day(day) 
FROM generate_series('2023-01-01'::date, '2024-01-01', '1 day') day;

Во время миграции критично следить за нагрузкой на диски и CPU. Утилита pg_stat_progress_copy показывает прогресс операций. А автовакуум будет очищать старые версии строк, не давая таблице разрастаться.

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

-- Перемещаем старую партицию на другое табличное пространство
ALTER TABLE transactions_2023_01 
SET TABLESPACE cold_storage;

-- Отключаем автовакуум для старых партиций
ALTER TABLE transactions_2023_01 
SET (autovacuum_enabled = false);

Для автоматизации рутины помогает расширение pg_partman. Оно создает новые партиции заранее и может автоматически архивировать старые:

SELECT partman.create_parent(
    'public.transactions',
    'created_at',
    'range',
    'month',
    p_premake := 3
);

И последнее: партиционирование требует изменений в приложении. Запросы без указания партиционного ключа будут сканировать все партиции. А значит, нужно научить ORM всегда добавлять created_at в условия поиска.

🏴‍☠️ @happy_devops

MongoDB, PostgreSQL и Elasticsearch предлагают разные подходы к партиционированию. И дело не только в терминологии — каждая база данных реализует его по-своему, со своими преимуществами и ограничениями.

В PostgreSQL после версии 10.0 появилось декларативное партиционирование. Создаём основную таблицу, указываем стратегию разделения, и база сама распределяет данные по дочерним таблицам. Партиции наследуют структуру родительской таблицы, но могут хранить данные на разных табличных пространствах. Под капотом PostgreSQL использует ограничения и триггеры для маршрутизации данных.

MongoDB строит партиционирование на концепции шардинга. Каждый шард — отдельный сервер или набор реплик. Данные распределяются по шардам на основе ключа. Интересная фишка — зоны шардинга. Можно связать диапазоны ключей с конкретными шардами и тем самым контролировать, где живут данные. Балансировщик следит за равномерным распределением нагрузки.

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

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

Главный подводный камень во всех базах — запросы, которые работают с несколькими партициями. PostgreSQL приходится объединять данные из разных таблиц, MongoDB собирает результаты со всех затронутых шардов, а Elasticsearch балансирует нагрузку между узлами. Чем больше партиций затрагивает запрос, тем сложнее его выполнить.

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

На практике выбор стратегии партиционирования часто диктуется не только техническими, но и организационными требованиями. Команда может быть более опытна в работе с одной из баз данных, или инфраструктура лучше подходит для определённого подхода.

🏴‍☠️ @happy_devops

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

В основе партиционирования лежит простая идея — разделить большую таблицу на маленькие части по какому-то признаку. База будет работать с каждой частью как с отдельной таблицей, но для приложения всё останется единым целым. И тут важно не путать партиционирование с шардированием.

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

Партиционирование по времени — самый популярный вариант. Логи, метрики, исторические данные — всё, что имеет временную метку, можно разбить по дням, неделям или месяцам. База будет быстро находить нужный диапазон и не тратить время на сканирование старых данных. А ещё появится возможность по-разному хранить старые и новые данные: свежие держать на SSD, а исторические переносить на медленные диски.

Географическое партиционирование спасает распределённые системы. Данные европейских клиентов живут в европейских дата-центрах, азиатских — в азиатских. Запросы летят к ближайшему серверу, задержки минимальны. Только придётся продумать, что делать с путешествующими пользователями.

Партиционирование по хешу равномерно распределяет данные между частями. Это полезно, когда нет явного признака для разделения, но нужно распределить нагрузку. База считает хеш от выбранных полей и решает, куда положить строку. Минус один — сложно понять, в какой партиции искать конкретную запись.

Из реальной практики: один проект страдал от медленных запросов к логам. Таблица разрослась до нескольких терабайт, индексы не помогали. Разбили данные по дням — и запросы ускорились в десятки раз. Зато другой проект потратил месяц на внедрение партиционирования, а в итоге только усложнил поддержку базы. Потому что не учли: если 90% запросов читают данные из всех партиций, разделение только навредит.

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

🏴‍☠️ @happy_devops

Как EXPLAIN помогает находить проблемы в типичных запросах.

Индексы и EXPLAIN — главные инструменты для отладки производительности в PostgreSQL. Планировщик выбирает путь выполнения запроса на основе статистики, а EXPLAIN показывает, насколько удачным был этот выбор.

Возьмем типичный запрос поиска заказов за последний месяц с джойном на таблицу пользователей:

EXPLAIN ANALYZE
SELECT o.id, o.created_at, u.email
FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.created_at >= CURRENT_DATE - INTERVAL '30 days'
  AND o.status = 'completed';

->  Hash Join  (cost=19.15..729.45 rows=238 width=80) (actual time=0.432..5.512 rows=245)
      Hash Cond: (o.user_id = u.id)
      ->  Seq Scan on orders o  (cost=0.00..685.20 rows=238 width=56)
            Filter: (status = 'completed') AND (created_at >= (CURRENT_DATE - '30 days'::interval))
      ->  Hash  (cost=12.40..12.40 rows=540 width=36)
            ->  Seq Scan on users u  (cost=0.00..12.40 rows=540 width=36)

Sequential Scan в плане запроса — первый звоночек. База читает всю таблицу orders, чтобы найти записи за последний месяц. Создадим индекс по дате создания и статусу:

CREATE INDEX idx_orders_date_status ON orders(created_at, status);

EXPLAIN ANALYZE SELECT ...
->  Hash Join  (cost=19.15..129.45 rows=238 width=80) (actual time=0.132..0.512 rows=245)
      Hash Cond: (o.user_id = u.id)
      ->  Index Scan using idx_orders_date_status on orders o  (cost=0.00..85.20 rows=238 width=56)
            Filter: (status = 'completed') AND (created_at >= (CURRENT_DATE - '30 days'::interval))
      ->  Hash  (cost=12.40..12.40 rows=540 width=36)
            ->  Seq Scan on users u  (cost=0.00..12.40 rows=540 width=36)

Index Scan и время выполнения упало в 10 раз — именно то, что нужно. Но обратите внимание на Seq Scan для таблицы users. База все еще читает ее целиком, хотя мы достаем только email. Самое время для покрывающего индекса:

CREATE INDEX idx_users_email ON users(id) INCLUDE (email);

EXPLAIN не просто показывает план, но и помогает его улучшить. Главное — понимать, что стоит за каждой строчкой его вывода.

🏴‍☠️ @happy_devops

EXPLAIN — основной инструмент для отладки производительности запросов в PostgreSQL. За сухими цифрами и техническими терминами в его выводе скрываются истории о том, как база данных пытается максимально быстро найти нужные данные.

Планировщик PostgreSQL выбирает путь выполнения запроса на основе статистики и эвристик. Sequential Scan — самый простой способ, перебор всех строк таблицы. Index Scan использует индекс и подходит для точечных запросов. Bitmap Scan комбинирует несколько индексов, собирая битовую карту подходящих строк.

Parallel Sequential Scan означает, что база распределила нагрузку между несколькими процессами. Звучит круто, но если запрос часто выполняется — лучше помочь базе правильным индексом. Nested Loop, Hash Join и Merge Join — разные стратегии объединения таблиц, каждая со своими сильными сторонами.

EXPLAIN ANALYZE не просто показывает план, но и реально выполняет запрос. В выводе появляются actual time и actual rows — реальное время выполнения и количество обработанных строк. Если цифры сильно отличаются от estimated — планировщик работает с устаревшей статистикой.

Высокие значения в startup time говорят о длительной подготовке операции. Большая разница между loops planned и loops actual намекает на проблемы с кардинальностью. А buffers shared hit против buffers shared read показывает, насколько эффективно работает кэш.

Partial и parallel стоит внимательно изучить. Partial Mode означает, что база выбрала только часть данных. А чем больше workers запущено в parallel, тем важнее следить за нагрузкой на CPU и диск — параллельное выполнение требует ресурсов.

Бывает, что индекс есть, а база его игнорирует. Причин масса: от слишком большого процента подходящих строк до неудачной формулировки WHERE. Особенно коварны неявные преобразования типов и функции в условиях — они мешают использовать индексы.

И последнее: EXPLAIN ANALYZE реально выполняет запрос. На больших таблицах это может занять много времени. Если нужно только проверить план — используйте обычный EXPLAIN. А для анализа боевых систем присмотритесь к auto_explain, он покажет планы запросов прямо в логах.

🏴‍☠️ @happy_devops

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

PostgreSQL предлагает несколько типов индексов, и каждый подходит для своих сценариев. B-tree индексы — стандартный выбор для большинства случаев. Они эффективны для поиска по точному совпадению и для диапазонных запросов. GiST индексы незаменимы для геоданных и полнотекстового поиска. Hash индексы работают только с равенством, зато делают это максимально быстро.

Создание индекса — это только начало пути. Планировщик запросов не всегда использует доступные индексы, особенно если статистика устарела или запрос написан неоптимально. Команда EXPLAIN ANALYZE показывает реальный план выполнения запроса. Если вместо Index Scan видите Sequential Scan — самое время разобраться, почему индекс игнорируется.

При создании составных индексов порядок колонок критически важен. Индекс по (last_name, first_name) поможет найти всех однофамильцев, а вот индекс по (first_name, last_name) для такого запроса будет бесполезен. Первая колонка должна быть самой селективной — той, что лучше всего сужает результаты поиска.

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

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

Покрывающие индексы позволяют получить все нужные данные прямо из индекса, без обращения к таблице. Для этого в INCLUDE нужно добавить все колонки, которые встречаются в SELECT. Такие индексы занимают больше места, но могут радикально ускорить запросы.

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

Мониторинг использования индексов не менее важен, чем их создание. pg_stat_user_indexes показывает, как часто используется каждый индекс. Если индекс не используется месяцами, а места занимает много — стоит задуматься о его удалении.

🏴‍☠️ @happy_devops

💥 Анонс! Анонс! Анонс! 💥

Каждому нужен близкий человек, которому можно кидать мемы. Это почти физиологическая потребность. У меня, к сожалению, такого человека нет и поэтому я просто решил кидать мемы всем🤷‍♂️

Я уже давно говорил, что хочу запилить канал с мемами и вот оно свершилось. Раньше в этом канале были смешные картиночки, но теперь он стал большой и серьезный, уже как-то несолидно. Да и хотелось что-нибудь сделать на базе ИИ.

🎹 ДевопсРадио v.1.0.1

Канал ведет специально обученный бот, который сам, на основе невероятного ИИ (обученного на всратом чувстве юмора, моем и группы товарищей), ищет и отбирает мемы по всему интернету. Телеграм, Реддит, ВК, Лепра и еще пачка всяких мемных помоек регулярно подвергаются его обходу. Он пока не очень умный, поэтому я все-таки аппрувлю то, что он находит. Но! Один мем в сутки он постит самостоятельно и я не знаю какой, пока он не появится в канале 😊 Свободу роботам и все дела 🤖

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

Но это еще не все. "Радио" в названии не так-то просто присутствует, в следующем релизе я реально запилю радио. Я очень привык работать под всякую приятную музычку типа lounge, chiilout, ambient, nu-jazz и тому подобное. Но с замедлением ютуба у меня отобрали мои любимые 10-часовые подборки лаунжа. А еще на ютубе есть специальная фоновая музыка для СДВГ-шников и вот примерно такое и будет транслироваться на моем радио. А мой суперумный бот будет помогать скачать понравившиеся треки.

Там еще куча разного интересного в бэклоге есть, но не буду рассказывать про все сразу, пусть будет небольшая интрига😏

Пока что просто отборные (и немножко проклятые) мемы❤️

🔞 Картинки нецензурные и неполиткорректные, без уважения к личности, гендеру, религии и политическим взглядам. Сексизм, расизм и долбоебизм присутствуют в полном объеме. Котики правят миром, про котиков только хорошее 🐈

🔜 Подписывайтесь на ДевопсРадио 🎹

〰️〰️〰️〰️〰️〰️〰️
🗞 @boombah_in_da_house

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

Инженеры по производительности баз данных — настоящие детективы. Они расследуют медленные запросы, ищут узкие места и находят способы ускорить работу системы. Каждый день они сталкиваются с новыми вызовами: от точечной настройки индексов до масштабных операций по шардированию данных.

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

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

Колоночные хранилища ClickHouse и Vertica раскрывают свой потенциал в аналитических системах. Они обрабатывают огромные массивы данных на лету при условии правильно спроектированной схемы и настроенных агрегаций.

Time-series базы данных InfluxDB и Prometheus специализируются на работе с метриками и логами. Их внутренняя архитектура оптимизирована под запись и чтение временных рядов, что делает их незаменимыми для мониторинга.

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

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

На этой неделе разберем тонкости настройки разных типов баз: от PostgreSQL до MongoDB и Elasticsearch. Поговорим про инструменты диагностики, разберем популярные проблемы и обсудим стратегии масштабирования.

🏴‍☠️ @happy_devops

Service Mesh — не серебряная пуля. После недели глубокого погружения в тему становится очевидно: это мощный инструмент, который может как решить кучу проблем, так и создать новые.

С одной стороны, Service Mesh дает нам богатый набор фич из коробки: трассировку запросов, умную балансировку нагрузки, гранулярный контроль трафика. Envoy в качестве прокси показывает отличную производительность, а Istio берет на себя всю головную боль с конфигурацией и обновлением правил. Добавьте сюда автоматический сбор метрик, защиту от каскадных отказов и canary deployments — получается внушительный список преимуществ.

Но у каждого плюса есть своя цена. Дополнительный прокси-слой — это overhead по CPU и памяти. Control plane требует отдельных ресурсов и внимания. Отладка проблем становится сложнее, потому что теперь между сервисами есть еще один слой абстракции. А уж если что-то пошло не так с самим Service Mesh — готовьтесь к веселому дебагу.

В итоге все сводится к старому доброму "зависит от контекста". Если у вас десяток микросервисов и простая топология — Service Mesh может оказаться из пушки по воробьям. Но если счет идет на сотни сервисов, если вам нужен серьезный мониторинг и контроль трафика — инвестиция в Service Mesh окупится сторицей.

Главное — помнить, что это инструмент, а не волшебная палочка. И как любой инструмент, его нужно грамотно готовить и правильно использовать.

🏴‍☠️ @happy_devops

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

Service Mesh и конкретно Istio + Envoy дают мощный инструментарий для трассировки. Весь трафик проходит через прокси, а значит, мы можем видеть каждый запрос, его путь и время выполнения. Но настроить это все правильно — задача нетривиальная.

Начнем с базовой конфигурации. В Istio включаем трейсинг через конфиг:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100
        zipkin:
          address: jaeger-collector.observability:9411

Тут мы говорим: "Собирай все запросы (sampling: 100) и отправляй их в Jaeger через Zipkin протокол". На проде sampling обычно ставят 1-10%, иначе можно захлебнуться в данных.

Теперь нужно научить наши сервисы пробрасывать trace контекст. Istio автоматически добавляет заголовки x-request-id, x-b3-traceid и другие. Но для полной картины стоит добавить инструментацию в код:

from opentelemetry import trace
from opentelemetry.instrumentation.flask import FlaskInstrumentor
from opentelemetry.instrumentation.requests import RequestsInstrumentor

app = Flask(__name__)
FlaskInstrumentor().instrument_app(app)
RequestsInstrumentor().instrument()

@app.route('/api/order')
def create_order():
    tracer = trace.get_tracer(__name__)
    with tracer.start_as_current_span("process_order") as span:
        span.set_attribute("order_type", "regular")
        result = process_order()
        return result

Такой код не только подхватит trace контекст из заголовков, но и добавит свои спаны с дополнительной информацией. В Jaeger мы увидим не просто вызовы между сервисами, а конкретные операции внутри каждого сервиса.

А вот пример конфигурации для отлова проблем производительности:

apiVersion: networking.istio.io/v1alpha3
kind: Telemetry
metadata:
  name: trace-sampling
spec:
  selector:
    matchLabels:
      app: orders
  tracing:
  - randomSamplingPercentage: 100.0
    customTags:
      http.status_code:
        header:
          name: :status
          defaultValue: "200"
      request.size:
        header:
          name: content-length
          defaultValue: "0"

Здесь мы добавляем кастомные теги для каждого трейса — HTTP статусы и размеры запросов. Это поможет быстрее находить проблемные паттерны.

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

И последний совет — не пытайтесь трейсить все подряд. Определите критичные бизнес-операции и сфокусируйтесь на них. Иначе рискуете утонуть в море бесполезных данных.

🏴‍☠️ @happy_devops

В современном Service Mesh Envoy — это основная рабочая сила, а Istio — генерал, который командует армией прокси-серверов. Каждый сервис получает свой персональный Envoy (sidecar), а Istio через control plane раздает этим Envoy указания: кого пускать, кого блокировать, как балансировать нагрузку.

Когда микросервис хочет поговорить с соседом, его запрос сначала попадает в локальный Envoy. Тот сверяется с картой маршрутов от Istio и принимает решение: пропустить запрос, перенаправить на другую версию сервиса или вообще отклонить. Такая архитектура превращает сеть микросервисов в управляемую структуру — какие бы правила не придумал оператор, они моментально распространяются на все прокси.

Вот пример базовой конфигурации Envoy для обработки входящего HTTP-трафика:

static_resources:
  listeners:
  - name: http_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 8080
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: local_service
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  
  clusters:
  - name: local_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: local_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 8081

А вот как настраивается более продвинутая конфигурация с retry policy и circuit breaker:

clusters:
  - name: local_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    circuit_breakers:
      thresholds:
        - priority: DEFAULT
          max_connections: 1000
          max_pending_requests: 1000
          max_requests: 1000
          max_retries: 3
    retry_policy:
      retry_on: connect-failure,refused-stream,unavailable
      num_retries: 3
      per_try_timeout: 1s
    load_assignment:
      cluster_name: local_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 8081

В финальной конфигурации часто добавляют health checks и outlier detection:

clusters:
  - name: local_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    health_checks:
      - timeout: 1s
        interval: 5s
        unhealthy_threshold: 3
        healthy_threshold: 1
        http_health_check:
          path: "/health"
    outlier_detection:
      consecutive_5xx: 5
      base_ejection_time: 30s
      max_ejection_percent: 50

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

В итоге Service Mesh на базе Istio и Envoy — это как операционная система для микросервисов. Разработчикам не нужно думать о network resilience, service discovery или сборе метрик. Все эти задачи делегированы инфраструктурному слою. А значит, команды могут сфокусироваться на бизнес-логике, не изобретая велосипеды для базовых сетевых операций.

🏴‍☠️ @happy_devops

Борьба с латентностью в микросервисной архитектуре — это вечная битва. Service Mesh и конкретно Istio дают мощный арсенал инструментов для этой войны. Только вот документация Istio напоминает инструкцию к боевому истребителю — куча кнопок, а как их правильно нажимать, не всегда понятно.

Начнем с основ конфигурации timeout и retry. В реальном мире сервисы тормозят, падают и теряют пакеты. Сетевые таймауты и повторные попытки — это наша первая линия обороны. Вот базовая конфигурация VirtualService для управления таймаутами:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payment-service
spec:
  hosts:
  - payment-service
  http:
  - route:
    - destination:
        host: payment-service
        subset: v1
    timeout: 3s
    retries:
      attempts: 3
      perTryTimeout: 1s
      retryOn: connect-failure,refused-stream,5xx

Этот конфиг говорит: "Если платежный сервис не ответил за 3 секунды или вернул ошибку — делаем еще три попытки, каждая по секунде". Обратите внимание на retryOn — здесь перечислены условия для повторных попыток. В продакшене часто добавляют gateway-error и reset для борьбы с сетевыми глюками.

Но одни таймауты не спасут от каскадных отказов. Тут в бой вступает circuit breaker. Его задача — вовремя понять, что сервис болеет, и перестать его мучить запросами. Настраивается через DestinationRule:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: payment-circuit-breaker
spec:
  host: payment-service
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 10

Тут мы говорим: "После 5 ошибок подряд в течение 10 секунд выключаем проблемный под на 30 секунд". MaxEjectionPercent защищает от ситуации, когда все поды вырублены — минимум 50% останутся в строю. А connectionPool не дает завалить сервис лавиной запросов.

Теперь самое интересное — rate limiting. В продакшене часто бывает, что один сервис-сосед начинает долбить твой сервис миллионом запросов в секунду. Rate limiting помогает зарубить такие атаки на корню:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: payment-ratelimit
spec:
  workloadSelector:
    labels:
      app: payment-service
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.local_ratelimit
        typedConfig:
          "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
          statPrefix: http_local_rate_limiter
          tokenBucket:
            maxTokens: 1000
            tokensPerFill: 100
            fillInterval: 1s
          filterEnabled:
            runtime_key: local_rate_limit_enabled
            default_value:
              numerator: 100
              denominator: HUNDRED

Этот монстр ограничивает входящий трафик до 100 запросов в секунду с возможностью буста до 1000 запросов. Важный момент — rate limiting лучше делать на уровне отдельных эндпоинтов, а не всего сервиса. Какие-то API могут быть тяжелыми и требовать жестких ограничений, а какие-то — легкими и способными переварить больше трафика.

Для мониторинга всей этой красоты нужны правильные метрики. Базовый набор:
- istio_request_duration_milliseconds — латентность запросов
- istio_requests_total — количество запросов с разбивкой по кодам ответа
- istio_request_bytes — размер запросов
- envoy_cluster_upstream_rq_pending_overflow — сработавшие circuit breaker
- envoy_cluster_upstream_rq_retry — количество повторных попыток
- envoy_http_ratelimit_total_requests_denied — отклоненные rate limiter запросы

🏴‍☠️ @happy_devops

Алерты стоит ставить не только на высокую латентность, но и на аномальное количество ретраев и срабатываний circuit breaker. Это часто помогает поймать проблемы до того, как они выльются в полноценный инцидент.

И последний совет: не включайте все фичи сразу. Начните с базовых таймаутов и ретраев, убедитесь что все работает как надо. Потом добавьте circuit breaker, настройте его пороги. И только потом, если нужно, переходите к rate limiting. Постепенное внедрение позволит избежать ситуации, когда Service Mesh сам становится источником проблем.

🏴‍☠️ @happy_devops

DevOps живет в состоянии непрерывного развития — стоит только освоить один инструмент, появляется три новых, а у проверенных решений открываются неожиданные грани.

Мы запускаем серию глубоких технических погружений: каждую неделю берем одну тему и докапываемся до сути, раскладывая по полочкам все нюансы — от service mesh и мониторинга до шардирования и распределенных хранилищ.

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

Эту неделю мы посвятим Service Mesh Architecture — разберем, как правильно готовить микросервисы с Istio и Linkerd, настраивать трассировку и балансировку, и почему service mesh — это не всегда серебряная пуля.

🏴‍☠️ @happy_devops

Service Mesh в микросервисной архитектуре часто сравнивают с нервной системой организма. И не зря — он контролирует взаимодействие сервисов, следит за их здоровьем и реагирует на проблемы. Только вот внедряют его обычно, когда организм уже болен: микросервисы размножились, латентность выросла, а в логах творится полный хаос.

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

Представьте себе крупный интернет-магазин. Заказ проходит через десяток сервисов: корзина, платежи, склад, доставка, уведомления... И каждый сервис должен знать, как общаться с остальными. Где они находятся, какие у них эндпоинты, как авторизоваться, что делать при таймаутах. Добавьте сюда версионирование API, балансировку нагрузки, и мониторинг — получается гремучая смесь.

Service Mesh берет эту головную боль на себя. Он добавляет к каждому сервису прокси-компонент (sidecar), который перехватывает весь входящий и исходящий трафик. Теперь сервисам не нужно знать друг о друге — они общаются через прокси, а уже он решает, куда и как доставить запрос.

Звучит как еще один слой сложности? Да, но эта сложность того стоит. Service Mesh дает готовые решения для типичных проблем распределенных систем. Трассировка запросов? Включается одним конфигом. Защита от каскадных отказов? Circuit breaker из коробки. Постепенный переход на новую версию сервиса? Canary deployment без единой строчки кода.

Но не спешите внедрять Service Mesh только потому, что это модно. Для небольших систем он может оказаться из пушки по воробьям. Накладные расходы на прокси, сложность отладки, дополнительные ресурсы — это та цена, которую придется заплатить. Прежде чем решиться, задайте себе вопрос: действительно ли ваши сетевые проблемы стоят этих затрат?

А вот если у вас правда болит голова от управления трафиком между сервисами — Service Mesh может стать тем самым обезболивающим. В следующих постах разберем конкретные примеры и поговорим, как готовить Service Mesh правильно.

🏴‍☠️ @happy_devops

Debug Adapter Protocol: включаем универсальный режим отладки 🎯

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

Разработчики умеют писать крутой код, но часто спотыкаются на банальной отладке. И не потому, что руки не из того места — просто каждая IDE и язык программирования приходят со своим отладчиком. А переучиваться никто не любит. Особенно когда приходится жонглировать между несколькими проектами на разных языках.

DAP (Debug Adapter Protocol) решает эту головоломку раз и навсегда. Представьте: один протокол, который работает с любым отладчиком, в любой IDE. VS Code, Eclipse, Atom или вообще свой редактор — без разницы. И это не просто красивые слова — DAP внедряют даже консервативные компании, которые обычно не спешат с новыми технологиями.

// Пример конфигурации DAP в VS Code
{
    "type": "node",
    "request": "launch",
    "name": "Debug Node.js",
    "program": "${workspaceFolder}/app.js",
    "skipFiles": [
        "<node_internals>/**"
    ],
    "resolveSourceMapLocations": [
        "${workspaceFolder}/**",
        "!**/node_modules/**"
    ]
}

DAP общается с отладчиком через JSON-RPC. Звучит сложно, но на деле упрощает жизнь. Хотите точки останова в TypeScript? Или может пошаговую отладку Python? DAP справится с обоими случаями без дополнительной настройки. Протокол поддерживает все стандартные функции отладки: пошаговое выполнение, условные брейкпоинты, просмотр переменных и выражений.

# Базовый обработчик событий DAP
async def handle_initialize(self, args):
    response = {
        # Поддержка подтверждения завершения настройки
        "supportsConfigurationDoneRequest": True,
        # Показ значений при наведении мыши
        "supportsEvaluateForHovers": True,
        # Отключаем откат на шаг назад при отладке
        "supportsStepBack": False,
        # Разрешаем менять значения переменных на лету
        "supportsSetVariable": True,
        # Поддержка перезапуска отладочной сессии
        "supportsRestartRequest": True,
        # Информация о загруженных модулях
        "supportsModulesRequest": True,
        # Возможность прервать отлаживаемый процесс
        "supportTerminateDebuggee": True,
        # Отложенная загрузка стека вызовов
        "supportsDelayedStackTraceLoading": True
    }
    return response

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

И самое приятное — DAP становится стандартом де-факто. Microsoft, JetBrains, Amazon — все крупные игроки его поддерживают. Даже такие специфические инструменты как удаленная отладка контейнеров или отладка встраиваемых систем постепенно переходят на DAP. А для разработчиков это значит меньше времени на настройку окружения и больше времени на написание кода.

PS Для тех, кто не знал: у нас есть бот для обратной связи @HDFeedBackBot Туда можно задать свои вопросы, например на тему технологий или аспектов нашей работы, про которые вы хотите увидеть пост. В нашей редакции работают крутые инженеры и мы обязательно разберемся и что-нибудь напишем

🏴‍☠️ @happy_devops

📣Анонс мероприятия

Всем привет!
Серое небо и короткий световой день сподвигают нас к организации теплых вечерних встреч в домашнем формате. Первая из них случится уже на следующей неделе в кофейне с символичным названием "культурный код" по адресу Москва, улица Чаянова 12, метро Новослободская. Там мы, fournines.ru, совместно с Андреем Синицыным (золотым профессионалом и автором двух крутых тг каналов) погрузимся в захватывающий мир SRE, посмотрим на него с технической и менеджерской сторон, сломаем отказоустойчивую систему, послушаем много интересного и ответим на все-все вопросы (ну и куда же без захватывающих историй).

📆 Дата: 11.12.24

⏰ Время: с 19:30 до 22:00

📍Место: «Культурый код», Москва, метро Новослободская, улица Чаянова 12

Вход бесплатный, а по промокоду

FREECOFFEE

можно получить бесплатный кофе🤫
Количество мест ограничено!

По всем вопросам и для брони места и бесплатного кофе пишите @dagureevaa

#события @downtime_bar

AIOps против MLOps: разбираем модный хайп 🤖

Все вокруг заговорили об AIOps, но никто не разобрался, где тут собака зарыта. А между тем, шумиха вокруг этой темы растёт день ото дня. Пора расставить точки над i.

AIOps — не про искусственный интеллект в традиционном понимании. Тут нет магии и роботов, захватывающих мир. По сути, это набор инструментов для автоматизации рутины в мониторинге и эксплуатации. Представьте себе систему, которая сама находит аномалии в метриках, группирует алерты и предлагает решения типовых проблем.

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

А MLOps? Тут совсем другая история. MLOps занимается жизненным циклом ML-моделей: от разработки до деплоя в продакшен. Это как CI/CD, только заточенный под специфику машинного обучения. Датасеты, эксперименты, версионирование моделей — вот это всё.

MLOps-инженер налаживает пайплайны для обучения моделей, следит за качеством данных, настраивает мониторинг drift detection, собирает метрики для A/B тестов. Он работает на стыке классического девопса и data sciense, помогая превращать jupyter-ноутбуки в промышленные решения.

Прямой связи между AIOps и MLOps нет. Да, в AIOps используются элементы машинного обучения, но это как сравнивать молоток и верстак — инструменты из разных областей. AIOps помогает админам справляться с лавиной алертов и инцидентов, а MLOps нужен дата-сайентистам для причёсывания их пайплайнов.

Не ведитесь на маркетинговую шумиху. AIOps не сделает из вас специалиста по ML, а знание MLOps не поможет настроить мониторинг. Каждый инструмент решает свои задачи. И если вам надо выбрать, с чего начать — отталкивайтесь от боли, которую хотите закрыть.

🏴‍☠️ @happy_devops

Приземление данных и технологический суверенитет — два мощных тренда, круто изменивших глобальную IT-индустрию за последние пару лет. Большие корпорации оказались между молотом и наковальней: с одной стороны давят регуляторы и государства, с другой — падает эффективность бизнеса из-за новых ограничений.

Мир разделяется на цифровые регионы. Все строят свои экосистемы, защищают персональные данные граждан, развивают локальные технологии. На первый взгляд звучит здраво — пора слезать с иглы западного софта и железа. Локализация выглядит панацеей от санкционных рисков и цифрового колониализма.

Только в реальности все сложнее. Глобализация дала нам GitHub и опенсорс, совместные научные проекты и единые стандарты. Технологические барьеры между странами тормозят инновации и обмен опытом. Разработчикам приходится изобретать велосипед заново, вместо того чтобы брать готовые решения и развивать их дальше.

К тому же "железный занавес" в интернете работает так себе. Обойти блокировки не сложно, а вот бизнесу приходится тратить ресурсы на соответствие новым правилам. Компании вынуждены строить зеркальную инфраструктуру, дублировать данные, плодить сущности — и все ради формального соответствия требованиям. В итоге страдает конкурентоспособность национальных игроков.

Похоже, баланс между открытостью и защитой интересов придется искать еще долго. Пока одни страны закрываются и строят свои "национальные интернеты", другие продвигают идеи цифровой глобализации 2.0 — с новыми правилами игры и честной конкуренцией. А инженерам стоит внимательно следить за регуляторикой и готовиться к новым сценариям развертывания инфраструктуры. И да, учить китайский — никогда не знаешь, где придется поднимать следующий кластер.

Ваня на своем канале «Деплой» рассуждает на туже тему, и делает это очень мощно. В его фирменном стиле он раскладывает тему приземления данных по полочкам. Очень грамотный пост.

LLM Resource Hub — бесплатная база знаний для работы с языковыми моделями 🤖

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

В первом разделе собраны готовые нейронки с документацией и примерами использования. Во втором — тщательно отобранные видеоуроки, которые помогут разобраться даже в самых сложных концепциях машинного обучения. Дальше идут курсы от преподавателей MIT, Stanford и Berkeley — те самые, что обычно доступны только студентам этих вузов.

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

Материалы на английском, зато свежие — многие обновляются каждую неделю. База постоянно пополняется статьями из ведущих ML-конференций, исследованиями от крупных лабораторий и кодом для решения типовых задач в работе с большими моделями.

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

🏴‍☠️ @happy_devops

Продуктивность без выгорания: инсайды от опытных DevOps 🚀

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

В чем же их секрет? А в том, что они перестали быть заложниками "надо срочно" и "все горит". Внедрили практику тайм-блоков — два часа на инфру, час на мониторинг, полчаса на код-ревью. Пока время не вышло — никаких переключений. А главное — научились говорить "нет" внезапным таскам, которые прилетают поверх планов.

Еще один лайфхак — короткие спринты в стиле помодоро. Полчаса работаем, потом десять минут отдыхаем. За перерыв успеваем и кофе выпить, и размяться, и даже пост в личный блог накатать. После четырех таких циклов — полноценный перерыв на обед или прогулку.

А еще эти ребята помешаны на автоматизации. Любую задачу, которая отнимает больше получаса в день — автоматизируют. Один раз потратить день на скрипт, зато потом месяцами экономить время на рутине. Создают шаблоны для типовых операций, пишут алиасы под частые команды, ведут библиотеку готовых решений.

И самое главное — после работы реально отключаются. Никаких уведомлений в мессенджерах, никакой почты по ночам. Если что-то критичное — в команде есть дежурный инженер. А остальные в это время занимаются своей жизнью: спортом, хобби, семьей. И знаете что? Именно такой подход делает их эффективнее тех, кто пытается быть онлайн 24/7.

🏴‍☠️ @happy_devops

AI-инструменты для разработки: от идеи до готового приложения за пару часов 🚀

Революция в веб-разработке набирает обороты — новые AI-сервисы превращают описание проекта в рабочий код буквально на лету. Давайте разберем самые крутые из них.

bolt.new — браузерная студия для быстрого прототипирования. Тут все работает прямо в браузере: описываете желаемый результат, правите дизайн, загружаете референсные картинки. С React-проектами справляется отлично, хотя с Vue и Nuxt пока дружит не очень. Готовый код можно скачать или сразу отправить в продакшн.

v0.dev — прямой конкурент bolt в создании лендингов, но со своими козырями. Главная фишка — использование библиотеки компонентов shadcn, благодаря которой ваш UI будет выглядеть современно и стильно. Недавно добавили интеграцию с GitHub-репозиториями, а деплой на Vercel делается буквально в пару кликов.

lovable.dev — тут мы переходим в высшую лигу. Это не просто генератор, а полноценная full-stack среда разработки в браузере. Поддержка баз данных Supabase, синхронизация с GitHub, полный доступ к исходникам — все включено. Описываете идею приложения или игры, и lovable превращает её в готовый продукт.

Cursor — это уже серьезная IDE для тех, кто готов работать с кодом на естественном языке. Говорите, что нужно сделать или изменить в проекте, а он пишет код. Умеет работать с документацией, искать решения онлайн, создавать и фронтенд, и бэкенд, интегрироваться с API. Нужны базовые знания о структуре проекта, но результат того стоит.

Windsurf — младший брат Cursor, но с амбициями. Работает локально, справляется с несколькими файлами одновременно, а недавно получил интеграцию с MCP (model context protocol). Это позволяет AI напрямую общаться с базами данных, серверами и файлами — звучит как фантастика, но работает уже сейчас.

Собрать рабочее приложение с этими инструментами проще простого: накидываете прототип в bolt.new, подгружаете скриншот любимого сайта для вдохновения, а финальную доводку делаете в Cursor или Windsurf. Деплой на Netlify или Vercel займет пару кликов.

И главное — все эти сервисы дают бесплатные тарифы для экспериментов. Идеально для создания прототипов или обучения современной веб-разработке.

🏴‍☠️ @happy_devops

Инструмент для отладки Dockerfile: buildg 🛠

В мире, где каждый второй проект — это монолит, раскиданный по сотне контейнеров, отладка Dockerfile превращается в квест. Добавил пару RUN команд, собрал образ, а он не работает. Собрал заново — та же история. И вот ты уже час гадаешь, что пошло не так.

buildg — новый инструмент на базе BuildKit для интерактивной отладки Dockerfile. Он позволяет ставить брейкпоинты на любую строчку, проверять состояние файловой системы после каждой команды и запускать терминал прямо внутри сборки.

Выглядит это так:

FROM ubuntu AS dev
RUN echo hello > /hello
RUN echo world > /world

Запускаем buildg debug, ставим брейкпоинт на третью строчку командой break 3, и погнали! После остановки можно зайти внутрь командой exec и посмотреть содержимое файлов. Никаких echo и printf — чистая интерактивная отладка, как в нормальном дебаггере.

Особенно приятно, что buildg работает с VS Code, Neovim и Emacs через Debug Adapter Protocol. Теперь можно отлаживать Docker-файлы в любимом редакторе с полноценным GUI. И да, он поддерживает rootless режим — никаких sudo прав не требуется.

В комплекте идет поддержка всех фич BuildKit: кэширование, SSH-агент, секреты. А для тех, кто использует nerdctl — buildg уже встроен как подкоманда.

💻 https://github.com/ktock/buildg

🏴‍☠️ @happy_devops

Психологическое здоровье в IT: табу, которое пора нарушить

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

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

А ведь базовые практики заботы о себе не требуют сверхчеловеческих усилий. Включите в календарь 10-минутные перерывы между созвонами. Настройте уведомления — пусть рабочий мессенджер молчит после семи вечера (если вы не на oncall конечно). Выделите час в день на прогулку или спортзал. Научитесь говорить "нет" авральным задачам, которые на самом деле не горят.

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

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

🏴‍☠️ @happy_devops

SSH-конфиг: 10 трюков для продвинутых админов ⚡️

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

Host позволяет создавать шаблоны для групп серверов. Звездочка в имени хоста автоматически подставит нужный домен и пользователя для всех подходящих машин:

Host web-*
    HostName %h.prod.company.com
    User deployer

ProxyJump открывает прямой путь к серверам за бастионами. Одна строчка заменит три-четыре команды для прыжков между хостами:

Host target
    ProxyJump jumphost1,jumphost2

ForwardAgent избавит от копирования ключей на промежуточные серверы. SSH-агент прокинет локальные ключи по всей цепочке хостов:

Host staging
    ForwardAgent yes
    AddKeysToAgent yes

LocalForward сделает удаленные сервисы локальными. База данных, Redis, Prometheus — всё станет доступно как localhost:

Host db
    LocalForward 5432 db.internal:5432

ControlMaster экономит время на повторных подключениях. Первая сессия станет мастером для всех следующих — они подключатся мгновенно:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/ctrl-%C

Compression спасет при работе через медленный VPN. Сжатие трафика ускорит отклик в несколько раз:

Host slow
    Compression yes
    CompressionLevel 9

IdentitiesOnly прекратит путаницу с ключами. SSH будет использовать только указанный ключ, игнорируя все остальные:

Host github.com
    IdentitiesOnly yes
    IdentityFile ~/.ssh/github

ServerAliveInterval сохранит соединение активным. Незаметные пинги не дадут серверу закрыть сессию по таймауту:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Match добавит гибкости в настройки. Запретите рут-доступ в нерабочее время или смените порт для определенных IP:

Match exec "date +%H | grep -q '1[7-9]'"
    PermitRootLogin no

RemoteForward расшарит локальные сервисы наружу. Два способа пробросить порт 80 на удаленный сервер — через конфиг или через ключ:

Host devbox
    RemoteForward 8080 localhost:80
    GatewayPorts yes

# или через ключ при подключении:
ssh -R 8080:localhost:80 devbox

Конфиг собирается в ~/.ssh/config с правами 600. И помни — SSH из коробки даст тебе намного больше, чем кажется на первый взгляд.

🏴‍☠️ @happy_devops

База данных для тех, кто устал от выбора базы данных

На дворе двадцатые годы, а мы до сих пор страдаем при выборе базы данных. MySQL? PostgreSQL? MongoDB? А может Redis? И каждый вендор кричит, что именно его решение — самое быстрое, масштабируемое и вообще единственно верное.

Сайт dbdb.io — находка для измученных душ. Это интерактивная энциклопедия баз данных, где собрана вся ключевая информация без маркетингового шума. Здесь каждая база разложена по полочкам: архитектура, особенности хранения данных, производительность и ограничения.

Круто, что создали его не маркетологи, а профессора из Университета Карнеги-Меллона. Они собрали исчерпывающую информацию о 250+ базах данных — от динозавров вроде IBM DB2 до молодых проектов типа CockroachDB.

За каждой статьей стоят пруфы: научные статьи, технические спецификации, реальные бенчмарки. Никакого "мы самые быстрые" без пруфов. И самое вкусное — интерактивные сравнения. Можно выбрать несколько баз и сравнить их по десяткам параметров. Прям мечта для технического обоснования!

И совет напоследок: не ведитесь на хайп. Загляните на dbdb.io перед тем, как притащить очередную модную NoSQL базу в продакшен. Сэкономите себе пару седых волос.

🏴‍☠️ @happy_devops

Книга "Apache Kafka" от O'Reilly — не просто очередной гайд по популярной технологии. За сухим названием прячется настоящая библия распределенных систем и потоковой обработки данных.

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

Отдельный респект за главу про консистентность и гарантии доставки сообщений. На пальцах разложили, почему at-least-once delivery — не серебряная пуля, и как выбирать между надежностью и производительностью. Да и вообще, книга отлично показывает trade-offs в распределенных системах.

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

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

Короче, must read для тех, кто работает с high-load и распределенными системами. Даже если вы не используете Kafka, принципы и паттерны из книги пригодятся в любой современной архитектуре.

🏴‍☠️ @happy_devops

Katacoda — песочница для DevOps без головной боли 🚀

Учиться на продакшене — так себе идея. А развернуть локально Kubernetes, Terraform или OpenShift порой сложнее, чем написать собственный оркестратор. Katacoda решает эту проблему: берёт на себя всю инфраструктуру и даёт нам готовую среду прямо в браузере.

В основе лежит запуск Docker-контейнеров с предустановленным набором инструментов. Выбираешь сценарий на сайте, кликаешь "Start Scenario" — и через 30 секунд у тебя готовая среда с терминалом:

# Проверим, что окружение поднялось
echo "Привет из Katacoda!"

# launch.sh инициализирует кластер Kubernetes
cat launch.sh
#!/bin/bash
minikube start --wait=false
minikube status
export KUBECONFIG=/etc/kubernetes/admin.conf

# Подождём, пока все поды поднимутся
kubectl wait --for=condition=Ready pod --all -n kube-system --timeout=180s

# Проверим, что кластер работает
kubectl get nodes

Главная фишка — интерактивные туториалы с автопроверкой. Система следит за каждой командой и подсказывает, если что-то идёт не так. Вот как выглядит проверка деплоймента:

# Создадим тестовый деплоймент
kubectl create deployment web --image=nginx
kubectl expose deployment web --port=80

# Katacoda проверит результат
verify_deployment() {
  POD_NAME=$(kubectl get pods -l app=web -o name)
  if [ -z "$POD_NAME" ]; then
    echo "Под не создан. Попробуй ещё раз!"
    return 1
  fi
  echo "Отлично! Деплоймент работает"
}
verify_deployment

За счёт веб-интерфейса отпадает нужда в мощной машине — весь тяжёлый lifting берёт на себя облако. Можно даже пробовать сложные штуки вроде распределённых систем или микросервисной архитектуры. Разворачивай хоть Kafka, хоть Elasticsearch — ничего не сломаешь.

И главное — не придётся объяснять начальству, почему твои эксперименты с Istio положили половину тестовой среды. А когда всё получится — просто перенесёшь рабочие конфиги в свою инфраструктуру.

🏴‍☠️ @happy_devops

Типичные грабли шардирования: выбираем правильный ключ 🔑

В позавчерашнем примере мы шардили базу по user_id и это кажется логичным и очевидным решением. Все данные одного юзера в одном месте, джойны не разъезжаются по базам — красота! Но это только на первый взгляд. В реальности такой подход приносит кучу проблем.

Представим соцсеть, где user_id используется как ключ шардирования. У одних пользователей тысячи постов и миллионы подписчиков, у других — пара репостов котиков. В итоге один шард разрывается от нагрузки, пока остальные скучают без дела. Получаем классический hot shard — и вся идея равномерного распределения летит в трубу.

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

Как выбрать ключ с умом? Отталкиваемся от паттернов доступа к данным. Для ленты новостей отлично подойдет шардинг по дате создания поста — свежий контент всегда под рукой. В e-commerce хорошо работает географический шардинг — заказы обычно привязаны к региону доставки.

В играх с открытым миром шардируем по координатам игровых зон. В системах логирования — по временным интервалам. В микросервисной архитектуре часто шардируют по tenant_id, чтобы данные одного клиента были изолированы.

Универсальное правило — ключ должен обеспечивать равномерное распределение данных и минимизировать cross-shard запросы. Если 80% запросов укладываются в один шард — значит ключ выбран правильно.

И не бойтесь сложных схем! Составной ключ из {region_id, created_at} или {category_id, product_id} часто работает лучше, чем один простой параметр. Главное — тщательно проанализировать характер нагрузки перед выбором стратегии шардирования.

PS Ссылка на картинку в хорошем разрешении

🏴‍☠️ @happy_devops

Увольнение: трагедия или новые возможности?

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

Первые дни после увольнения мозг генерит два типа мыслей. Первая: «Да как они посмели, я же их продакшен с колен поднимал!» Вторая: «А точно я не самозванец, и кому теперь нужен девопс без проектов?» Обе мысли ведут в никуда.

Любой минус можно развернуть в плюс. Пока у других тикеты горят, у вас появилось время на рефлексию. Какие технологии реально приносили пользу? Где костыли поддерживали мертвый код? Что хотелось изучить, но вечно не хватало времени?

Старая работа схлопнулась как кластер в пятницу — и освободила место для чего-то нового. Для тех проектов, где вас оценят не за готовность сидеть ночами, а за умение выстраивать процессы. Где можно будет внедрять современные практики, а не поддерживать легаси «потому что так исторически сложилось».

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

🏴‍☠️ @happy_devops

Пошаговый гайд по масштабированию в продакшене: от теории к практике 🚀

Разберем каждый этап масштабирования с реальными примерами и псевдокодом. Погнали!

Вертикальное масштабирование. Начинаем с простого — увеличиваем мощность серверов. Мониторим нагрузку через Prometheus:

# CPU под нагрузкой больше 80%
rate(node_cpu_seconds_total{mode="system"}[1m]) > 0.8

# RAM забит под завязку
node_memory_MemFree_bytes / node_memory_MemTotal_bytes < 0.1

Когда метрики в красной зоне — апгрейдим железо. Но это временное решение, пора думать о горизонтальном масштабировании.

Балансировка нагрузки — наш следующий шаг. Простой конфиг Nginx для Round Robin:

upstream backend {
    server app1.example.com:8080;
    server app2.example.com:8080;
    server app3.example.com:8080;
}

Теперь запросы равномерно распределяются между серверами. При падении одной ноды трафик автоматически уйдет на живые сервера.

База данных — самое интересное. Начинаем с репликации в PostgreSQL:

-- На мастере
CREATE PUBLICATION app_pub FOR ALL TABLES;

-- На реплике
CREATE SUBSCRIPTION app_sub 
CONNECTION 'host=master dbname=app'
PUBLICATION app_pub;

Когда и этого мало — включаем шардинг. Пример логики маршрутизации:

def get_shard(user_id):
    shard_num = user_id % TOTAL_SHARDS
    return f"shard_{shard_num}"

def save_data(user_id, data):
    shard = get_shard(user_id)
    shard_db = get_database(shard)
    shard_db.save(data)

Асинхронная обработка творит чудеса. Выносим тяжелые задачи в очереди:

# Вместо прямой отправки
def process_order(order):
    send_notification()  # блокирующая операция
    generate_invoice()   # тоже долго
    update_warehouse()   # и это тоже

# Используем очереди
def process_order(order):
    queue.publish('notifications', order_id)
    queue.publish('invoices', order_id)
    queue.publish('warehouse', order_id)
    return 'Processing started'

Кэширование — must have для высоких нагрузок. Redis спасает от лишних запросов к базе:

def get_user_data(user_id):
    # Сначала смотрим в кэш
    cached = redis.get(f"user:{user_id}")
    if cached:
        return json.loads(cached)
    
    # При промахе идем в базу
    data = database.query(user_id)
    redis.set(f"user:{user_id}", json.dumps(data), ex=3600)
    return data

Оптимизация кода не менее важна. Например, в Go используем горутины для параллельной обработки:

func processItems(items []Item) {
    resultChan := make(chan Result, len(items))
    
    for _, item := range items {
        go func(i Item) {
            result := heavyProcessing(i)
            resultChan <- result
        }(item)
    }
    
    // Собираем результаты
    var results []Result
    for range items {
        results = append(results, <-resultChan)
    }
}

И наконец, graceful degradation. Отключаем тяжелые фичи при высокой нагрузке:

def search_products(query):
    if is_high_load():
        # Простой поиск по точному совпадению
        return basic_search(query)
    else:
        # Полнотекстовый поиск с фильтрами
        return full_search(query)

def is_high_load():
    return cpu_usage > 80 or response_time > 500

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

PS: Ссылка на картинку в хорошем разрешении

🏴‍☠️ @happy_devops

Ссылку пофиксили, извините 🙈
На всякий случай https://t.me/+HlvAVVBNC2Y5ZmRi

Кстати. У нас есть островок здравого смысла в этом безумном море — чат "HappyDevops Club" для тех, кто устал от всякой мишуры и хочет нормального общения.

У нас в чате уже больше трехсот инженеров, которые не боятся делиться опытом и признавать ошибки. Никаких "я гуру, а вы все нубы" — только честные разговоры о том, как оно в реальной жизни. От монолитов до микросервисов, от legacy до облаков, от стартапов до энтерпрайза.

А еще у нас можно просто потрещать за жизнь. Потому что DevOps — не только про CI/CD и Kubernetes. Иногда нужно обсудить, куда податься после очередного сокращения, как не психануть от токсичного менеджера или где найти толковых джунов в команду.

У нас нет священных коров и запретных тем. Хочешь обсудить, почему новый фреймворк — это переоцененный хайп? Вперед! Считаешь, что все делают мониторинг неправильно? Докажи! Узнал классный хак для отладки продакшена? Делись!

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

🏴‍☠️ ЧАТ @happy_devops | https://t.me/+HlvAVVBNC2Y5ZmRi

Как пережить собеседование и не потерять веру в себя

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

За красивыми словами о культурном фите и командных ценностях прячется жесткая реальность: нас оценивают, сравнивают и часто отвергают. А после очередного rejection letter самооценка падает ниже уровня продакшена в пятницу вечером.

Но собеседование — не экзамен на профпригодность. Это диалог двух профессионалов. Интервьюер ищет не энциклопедию на ножках, а человека, который умеет думать и решать проблемы. Не знаешь точный флаг kubectl? Расскажи, как будешь искать решение. Забыл синтаксис ansible? Объясни логику работы.

Записывайте каждое собеседование. Не ответы — ощущения. Где начали нервничать? Какие вопросы поставили в тупик? Что можно было сказать иначе? Превратите каждый фейл в точку роста.

И помните: любой сеньор когда-то путал local с global scope, а идемпотентность вызывала у него нервный тик. Опыт приходит со временем, а умение учиться на ошибках — бесценный скил для девопса.

Ну и лайфхак напоследок: после сложных вопросов выдыхайте. Буквально. Глубокий вдох поможет мозгу переключиться и найти решение. А rejection letter сохраните — через год перечитаете и посмеетесь.

🏴‍☠️ @happy_devops

HuggingFace для занятых: нейронки без лишней мороки 🤖

HuggingFace — это как GitHub для ML моделей. Но вместо кода тут нейронки, а вместо веток — разные версии весов. И поиск тут работает в разы удобнее: сразу видно метрики, примеры использования и сценарии применения.

Pipeline — главный инструмент для быстрого старта. Он инкапсулирует три этапа работы с моделью: подготовку данных, инференс и пост-обработку. На практике выглядит так:

from transformers import pipeline

# Базовый пайплайн для классификации
classifier = pipeline('sentiment-analysis')

# Продвинутый пайплайн с указанием модели и устройства
classifier = pipeline(
    task='sentiment-analysis',
    model='blanchefort/rubert-base-cased-sentiment',
    device=0  # 0 для GPU, -1 для CPU
)

Каждая модель на HuggingFace — как пакет на PyPI, только круче. Открываете карточку модели и видите:
🟣 Точность на тестовых данных
🟡 Размер модели и требования к железу
🔵 Готовые примеры кода
🟢 Список языков и форматов данных
🔘 Рейтинг от комьюнити

Для продакшена стоит использовать кэширование и батчинг:

# Кэшируем модель локально
from transformers import set_caching_enabled
set_caching_enabled(True)

# Батчинг для оптимизации
texts = ["Первый текст", "Второй текст", "Третий текст"]
results = classifier(texts, batch_size=32, truncation=True)

Искать модели просто: заходите в Models, выбираете задачу (Text Classification, Translation, Speech Recognition) и сортируете по рейтингу. Топовые модели всегда наверху, с ними точно не промахнетесь.

Для тяжелых моделей есть ускорители:

# Квантизация для уменьшения веса модели
classifier = pipeline('sentiment-analysis',
    model='blanchefort/rubert-base-cased-sentiment',
    torch_dtype='auto',  # автоматически выберет оптимальный формат
    device_map='auto'    # распределит по доступным устройствам
)

А для тонкой настройки под свои задачи HuggingFace предлагает Trainer API — но это уже тема для отдельного поста.

🏴‍☠️ @happy_devops

Work-life balance в IT: жизнь за пределами терминала 🌴

IT выжимает соки как никакая другая индустрия. Утренний стендап, деплой в прод, срочный хотфикс, вечерний созвон с заказчиком. А между ними — тонна тикетов, код-ревью и уведомления из чатов. К вечеру мозг превращается в кисель.

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

Работать на износ — путь в никуда. Профессиональное выгорание накроет быстрее, чем успеешь сказать "git push". А восстановление займёт месяцы. Целая индустрия психологов кормится с выгоревших айтишников — и это не шутка.

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

И запомните — никакой аврал не стоит здоровья. Продакшен упадёт и без вас, мир не рухнет. Отдохнувший девопс принесёт команде больше пользы, чем загнанный трудоголик со стажем работы 24/7.

🏴‍☠️ @happy_devops

⚡️ IT-link Осень 2024 — главная IT-конференция сезона

Вы ждали — мы сделали!

Приглашаем вас на IT-link Осень 2024 — уникальную площадку, где встретятся лучшие эксперты и профессионалы IT-индустрии.

Более 1000 участников и более 40 спикеров из таких крупнейших IT-компаний, как Сбер, VK, Яндекс, Авито, Т-Банк, ВТБ и МТС, соберутся вместе, чтобы обсудить самые актуальные темы, обменяться опытом и новыми идеями.

Участников конференции ждут 4 площадки:
1) Analytics;
2) Product&Design;
3) Development;
4) Интерактивная площадка: «Как завалить проект, не написав ни строчки кода»;

Не забудьте ознакомиться с программой

Встретимся с вами:
🔜 23 ноября, в 9:30
🔜 Конгресс-отель «Россия», г. Чебоксары
🔜 Онлайн/Офлайн формат. Для подключения к трансляции и доступа к презентациям нужно вступить в телеграм-чат

Станьте частью глобального IT-сообщества вместе с IT-link Осень 2024 🚀
И помните участие бесплатное, количество мест строго ограничено!

Зарегистрироваться

Токсичная команда: инструкция по выживанию в IT-аду 🔥

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

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

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

Политика в команде выедает мозг похлеще любого легаси-кода. Интриги, подковёрные игры, стукачество тимлиду. Каждый норовит подсидеть коллегу или свалить на него свои факапы. А грешки записывают и припоминают при первой возможности.

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

Помните главное — адекватные команды существуют. Где ценят специалистов, уважают личные границы и следят за work-life balance. Не тратьте жизнь на токсичное болото, которое маскируется под "особенности корпоративной культуры".

🏴‍☠️ @happy_devops

DevOps на фрилансе: как заработать без корпоративных войн 💻

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

На фрилансе DevOps-инженер становится универсальным солдатом. Тут нет роскоши специализироваться только на AWS или только на CI/CD. Придётся вникать во все этапы: от настройки инфраструктуры до мониторинга и поддержки. Зато растёшь как специалист в три раза быстрее.

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

К слову о проектах. На старте берите любые заказы, даже скучные и малооплачиваемые. Главное — набить портфолио и получить первые отзывы. Дальше сработает сарафанное радио: клиенты начнут приходить по рекомендациям.

Самое сложное на фрилансе — не технические задачи, а общение с клиентами. Придётся учиться говорить "нет" невыполнимым требованиям, грамотно оценивать сроки и доходчиво объяснять, почему автоматизация стоит таких денег.

А ещё помните про документацию. На фрилансе она спасает жизнь: проще продлить контракт с клиентом, когда он видит порядок в проекте. Да и другим девопсам после вас будет проще — карма в мире IT штука важная.

🏴‍☠️ @happy_devops

Импостер-синдром: не самозванец, а нормальный разработчик 🤔

В мире IT каждый второй прячет тайну — ощущение, будто он случайно оказался в профессии. Сидит на стендапе, рассказывает про крутой деплой, а внутренний голос нашептывает: "Да ты просто нагуглил решение, любой бы справился".

Многие годами страдают от этой фигни. А правда в том, что все через такое проходят. Даже те самые "гуру", которые на конференциях вещают про высоконагруженные системы. Они точно так же гуглят, спрашивают в чатах и иногда роняют прод.

А штука в том, что IT развивается слишком быстро. Невозможно знать всё. Тот, кто говорит, что разбирается во всем — либо врет, либо застрял в 2010-м. Нормальный девопс не тот, кто никогда не ошибается, а тот, кто умеет быстро находить решения и учиться на своих факапах.

Есть отличный пример — история про джуна, который неделю писал простенький скрипт для автоматизации. Опытные коллеги сделали бы это за пару часов. Но через месяц этот скрипт спас команде кучу времени, а джун получил бесценный опыт.

Сомнения в себе — признак роста. Когда специалист понимает, как много не знает — значит, он растёт профессионально. Главное не застрять в этих сомнениях, а использовать их как топливо для развития.

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

🏴‍☠️ @happy_devops

Работа мечты или мечты о работе: как понять, туда ли вы идете

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

Если вам это знакомо — возможно, пришло время задуматься о смене работы. Вот несколько тревожных звоночков:

1️⃣ Вы не чувствуете, что растете. Если за последний год вы не узнали ничего нового, не взяли на себя более сложные задачи — это повод задуматься. Возможно, вы переросли эту компанию.

2️⃣ Вам скучно. Задачи не вызывают интереса, энтузиазм приходится выдавливать из себя по каплям. Если единственное, что вас мотивирует — это зарплата, то, может, стоит поискать то, что будет вдохновлять?

3️⃣ Вы не разделяете ценности компании. Если вы идеологически не совпадаете с компанией, если ее цели и методы вызывают у вас неприятие — долго вы там не продержитесь.

4️⃣ Вы не видите перспектив. Ни карьерных, ни финансовых, ни каких-либо еще. Может статься, что в этой конторе вы уже достигли потолка.

5️⃣ У вас нет work-life balance. Если работа пожирает все ваше время и силы, не оставляя ресурса на личную жизнь, хобби, отдых — это нездорово. Никакая работа не стоит вашего здоровья и счастья.

Но не стоит бросать насиженное место только потому, что трава за забором кажется зеленее. Идеальных работ не бывает, везде свои трейдоффы. Главное — чтобы минусы не перевешивали плюсы.

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

А вы на своем месте или в поиске работы мечты? Поделитесь в комментариях, через что вам пришлось пройти, чтобы это понять. И лайк не забудьте, а то работодатель не заметит, какой вы инсайтфул 😉

🏴‍☠️ @happy_devops

Карьерный рост в DevOps: советы от тех, кто прошел путь от джуна до лида 🚀👨‍💻

Как пробиться в лиды, когда ты всего лишь джун? Как вырасти из толпы таких же зеленых падаванов в уважаемого мастера-джедая? Спойлер: никакой магии, только упорство, стратегия и немного удачи!

Вот что советуют те, кто уже прошел этот нелегкий, но увлекательный путь.

Первое и главное — непрерывно учитесь. Девопс — это не про то, чтобы один раз выучить пару команд и почивать на лаврах. Это про постоянное развитие, исследование новых технологий, методологий. Будьте в курсе трендов, но не гонитесь за хайпом. Изучайте фундаментальные вещи, которые не устареют через сезон.

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

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

Ищите ментора, станьте ментором. Опыт коллег — это кладезь знаний, глупо им не пользоваться. Найдите человека, которым восхищаетесь, и просите совета. А лучше — несколько людей с разными точками зрения. И не забудьте передать эстафету дальше — наставляйте тех, кто идет за вами.

И не забывайте про баланс! Карьера важна, но не в ущерб всему остальному. Высыпайтесь, занимайтесь спортом, уделяйте время хобби и близким. Выгоревший, замотанный трудоголик едва ли станет хорошим лидом. Заботьтесь о себе — это инвестиция в ваше будущее.

Как видите, нет какого-то одного секрета успеха. Это комплекс усилий, стратегия из множества шагов. Главное — не останавливаться, верить в себя и помнить, что даже самый длинный путь начинается с первого шага.

А какие советы дали бы вы начинающим девопсам? Расскажите в комментариях — возможно, именно ваш инсайт поможет кому-то вырасти из джуна в лида! Ну и лайк не забудьте, а то вдруг пропустите момент, когда станете тимлидом 😉

🏴‍☠️ @happy_devops

Networking для интровертов: как завести полезные связи, оставаясь собой

Знакомо чувство, когда все вокруг болтают о важности связей, а ты сидишь в уголке и мечтаешь стать невидимкой? Интровертам нетворкинг дается непросто. Но, как говорится, если гора не идет к Магомеду... придется Магомеду выползать из уютной пещерки!

Как же заводить полезные знакомства, оставаясь собой и не растрачивая весь запас социальной энергии?

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

Во-вторых, используйте онлайн. Интровертам часто проще общаться в интернете, чем вживую. Заведите профиль на LinkedIn, GitHub, в профессиональных сообществах. Комментируйте, делитесь опытом, задавайте вопросы. Глядишь, и завяжутся интересные дискуссии, а там и до реальных знакомств недалеко.

В-третьих, не забывайте про силу контента. Вам некомфортно самому начинать разговоры? Так пусть ваши идеи говорят за вас! Пишите статьи, туториалы, делитесь кейсами. Если контент полезный, люди сами потянутся. Вот вам и повод для знакомства.

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

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

Если вы тоже интроверт и у вас есть свои лайфхаки по нетворкингу, расскажите в комментариях! А пока лайк, чтобы эта тема не затерялась. Интровертам тоже нужны связи! 😉

🏴‍☠️ @happy_devops

Как сохранить дзен, когда все горит и рушится 🧘‍♂️

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

Давайте подумаем как с этой херней справляться.

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

Делайте перерывы. Даже если дедлайн горит, а дела не ждут. 5 минут на кофе, 10 на прогулку или полчаса на обед — это инвестиции в вашу продуктивность. Отвлекитесь, переключитесь, дайте мозгу отдохнуть. Глядишь, и решение само придет! ☕️

Не забывайте про командную работу. Вы же не одиночка на поле боя, у вас есть соратники! Делегируйте, обсуждайте, просите помощи. Разделенная нагрузка — это уже полдела. А еще лучше — автоматизируйте, документируйте, оптимизируйте. Чтобы в следующий раз было чуть легче.

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

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

Согласны? Или есть свои лайфхаки? Делитесь мыслями в комментах, ставьте лайк, пусть эта тема получит максимальный охват! Вместе справимся с любым авралом! 💪

🏴‍☠️ @happy_devops

Поговорим о проджектах 😎

Из моего опыта, проджекты бывают разными:
- Первые — толкатели тасок в джире, от которых примерно ноль пользы.
- Вторые — душнилы, которые научились играть в scrum, agile и теперь чинят препятствия бизнесу, потому что хотят все сделать идеально.
- Третьи — пиздаболы мечтатели, которые продают светлое будущее, работают в разных крутых компаниях, но при этом проекты не умеют доводить до конца.
- The last but not least — настоящие решалы, которые организуют команды, процессы и делают крутые штуки.

Хочу познакомить вас с Артемом — он руководит проектным и продуктовым офисом, который разивает технологическую платформу для разработчиков в Яндексе.
Вы когда-нибудь задумывались, каково это, когда ты продакт и разрабатываешь фреймворк для C++?
А раньше Артем отвечал за технологическое развитие в Сбере.

🔥Чтобы становиться проджектами, которые двигают мир вперед, а не таски, читайте, как стать тем:
- кто умеет решать проблемы
- кто умеет задавать вопросы
- кто умеет в work life balance
- кто понимает продукт и его техническую сторону не хуже какого-нибудь архитектора

👉 Подписывайтесь и будьте решалой!

▶️ Глава Microsoft умолял урезать его зарплату, но ее бесцеремонно повысили сразу на 63%

История, которая идеально иллюстрирует поговорку "хотели как лучше, а получилось как всегда". Представьте: вы глава гигантской IT-компании, случается эпичный провал с безопасностью, хакеры взламывают аккаунты чуть ли не самого Белого Дома. Вы просите урезать себе зарплату в качестве наказания и жеста ответственности. Благородно? Несомненно!
Но не тут-то было. Совет директоров Microsoft решил иначе: CEO Сатье Наделле не просто не урезали зарплату, а повысили на 63%! В итоге за год набежало почти $80 млн - на $30 млн больше, чем годом ранее.
И ведь не первый раз доходы CEO растут на фоне проблем компании. Не так давно Наделла получил внезапную прибавку сразу после того, как Microsoft уволила 10 000 сотрудников.
Особый метод мотивации топ-менеджмента? Поощрение за провалы и увольнения? Или левая рука не знает, что делает правая? Ситуация, мягко говоря, неоднозначная. Но факт остается фактом: просишь меньше - получаешь больше. Такие вот парадоксы в мире большого бизнеса.

▶️ Девушка едва не умерла из-за замечания начальника: Перестала есть, пить и двигаться

А вот вам история, от которой волосы дыбом встают. В Китае 20-летняя девушка Ли чуть не отправилась на тот свет из-за... обычного замечания начальника! После того, как босс ее отчитал, Ли впала в кататонический ступор: перестала есть, пить и двигаться.
Причем ситуация ухудшалась с каждым днем. Девушка буквально превратилась в "деревянного окоченевшего человека". Врачи диагностировали у нее тяжелую депрессию. Сама Ли оказалась довольно замкнутой личностью, поэтому не смогла никому рассказать о произошедшем, что только усугубило ее состояние.
История наделала шуму в китайских соцсетях. Пользователи писали, что Ли "истязала себя из-за действий босса", советовали "уходить с требовательной работы, а не страдать молча". Но многие признавались, что и сами испытывают стресс, однако уйти не могут - слишком сложно найти новое место.
Жуткая история, не правда ли? Конечно, мы не знаем всех деталей, но факт остается фактом: люди доводят себя до крайностей из-за токсичной работы и начальства.

▶️ Требования российских телеканалов к Google достигли 2 ундециллионов руб.

И напоследок новость, которая взрывает мозг.
Российские телеканалы выкатили Google требования на - внимание! - 2 ундециллиона рублей. Это единица и 36 нулей, если что. Как вам такой масштаб?
А началось все с того, что Google не восстановила аккаунты российских медиа на YouTube. Ну вы знаете, "Звезда", "Первый канал", ВГТРК и прочие. Суд дал компании 9 месяцев на исполнение, а за каждый день просрочки назначил штраф в 100 000 рублей. Казалось бы, не так уж и много по меркам Google.
Но тут в игру вступила безумная математика! Штраф начал удваиваться каждую неделю, причем без ограничения общей суммы. В итоге в сентябре набежало уже 13 дециллионов (это 33 нуля, на минуточку), а сейчас сумма достигла 2 ундециллионов. Для сравнения - число гугол, в честь которого названа компания, это "всего лишь" единица со 100 нулями.
Занавес этой театра абсурда - российский "Гугл" еще осенью был признан банкротом. То есть взыскивать эти сумасшедшие суммы, по сути, не с кого. Остается только гадать, какую цель преследовали телеканалы, выставляя такие требования. Может, хотели войти в книгу рекордов Гиннесса по размеру штрафа? Или просто решили поупражняться в написании чисел с огромным количеством нулей?

#новости_по_пятницам

🏴‍☠️ @happy_devops

Хочешь расти в DevOps — помогай расти другим: менторство и обмен опытом

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

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

Менторство — это реальный инструмент развития, причём обоюдного. Делясь знаниями, мы не только помогаем коллегам, но и сами лучше структурируем свои навыки. Ведь лучший способ разобраться в предмете — объяснить его другому! К тому же менторство, это отличная прокачка софт-скиллов: коммуникации, лидерства, эмпатии.

И тут плавно переходим к обмену опытом. Друзья, какими бы крутыми мы себя ни считали, всегда найдется тот, кто разбирается лучше или знает хак, до которого мы не додумались. И это ок! Никто не рождался с Kubernetes в зубах и Terraform в подгузнике. Все мы учимся друг у друга, каждый день.

Так давайте использовать это по максимуму! Не стесняйтесь спрашивать совета у опытных коллег или предлагать помощь новичкам. Организуйте сессии обмена знаниями, пишите статьи, выступайте на митапах. Даже пост с разбором интересной проблемы в нашем чатике — уже вклад в общую копилку!

Главное не забывайте благодарить тех, кто помог. Признание в сообществе, ценнейшая награда для профессионала. Ну и нас не забудьте отблагодарить лайком, если пост зашел 😉

Let's make DevOps-экосистему еще более открытой и поддерживающей!

На сегодня всё, друзья. Не стесняйтесь, будьте менторами и менти, делитесь и перенимайте. Вместе мы сильнее! Увидимся в следующих постах, ну а пока – продуктивного дня!

🏴‍☠️ @happy_devops

Выгорание в IT: как распознать, преодолеть и предотвратить

Итак, сегодня будет серьезный разговор. О том, о чем многие предпочитают молчать, но что рано или поздно настигает каждого в нашей безумной индустрии. Да-да, речь про выгорание, профессиональный burnout 😰

Признайтесь, у кого в последнее время:
🔘 Пропал интерес к работе, даже любимые таски вызывают тоску и апатию
🔘 Продуктивность упала ниже плинтуса, на задачи уходит в 2 раза больше времени, чем раньше
🔘 Раздражают коллеги, бесят заказчики, выводит из себя малейший фидбек
🔘 Хочется забить на все и сбежать на Гоа, открывать серф-школу для бегемотов

Если вы насчитали больше двух пунктов, то у нас для вас плохие новости: вероятно, вы на пути к выгоранию или уже поджариваетесь на медленном огне. И это, поверьте, не шутки. Затяжной стресс, хроническая усталость, потеря мотивации — верные спутники выгорания, которые могут вывести из строя даже самого стойкого DevOps-бойца 🥊

К счастью, выгорание — это не приговор, а просто сигнал, что пора что-то менять. И вот вам наша тактика борьбы:

1️⃣ Признайте проблему. Да, это первый и самый сложный шаг. Но пока вы делаете вид, что все норм, вы только усугубляете ситуацию. Будьте честны с собой и окружающими, не стесняйтесь сказать "что-то я подустал, ребята". Поверьте, вас поймут.

2️⃣ Устройте диджитал-детокс. Отпишитесь от рабочих чатов хотя бы на выходные, не чекайте почту по вечерам, поставьте лимит на просмотр телеги, технических блогов и социалок (да-да, мы знаем про вашу привычку). Дайте мозгу перезагрузиться.

3️⃣ Вспомните, что кроме работы есть другая жизнь. Займитесь спортом, сходите в театр, почитайте бульварный роман. Переключитесь на что-то максимально далекое от IT, чтобы мозг отдохнул и заскучал по любимым алгоритмам.

4️⃣ Поговорите с руководством. Объясните ситуацию, предложите варианты: распределить часть нагрузки, взять мини-отпуск, поработать недельку из дома. Помните: вы — ценный ресурс, заботиться о вашем состоянии — в интересах компании.

5️⃣ Оцените свои перспективы. Если вы уже который месяц выгораете на текущем месте и не видите просвета, может быть, пора что-то кардинально поменять? Новый проект, новая компания, новая специализация, в конце концов. Главное - не принимайте решения на эмоциях.

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

Коллеги, запомните: выгорание — это не слабость и не повод для стыда. Это нормальная реакция организма на долгий стресс и перегрузки. Главное — вовремя распознать тревожные звоночки и принять меры. И мы верим: вам хватит мудрости и сил справиться с этим вызовом. В конце концов, не зря же мы выбрали одну из самых сложных и интересных профессий на свете? 😉

А если вам удалось победить выгорание или вы знаете действенные лайфхаки по профилактике, делитесь в комментах, не держите в себе! Давайте поддержим друг друга

И да, по традиции, просим вас поставить любую реакцию и поделиться этим постом, если он был полезен. Знаете же, как нам важна ваша поддержка и фидбек ❤️

На этом все, коллеги! Увидимся в следующих постах, ну а пока - берегите себя и свой душевный дзен!

🏴‍☠️ @happy_devops

Как DevOps-инженеру стать незаменимым: прокачиваем софт-скиллы

Привет, DevOps-гуру и те, кто только встал на этот путь! Сегодня поговорим о том, что отличает просто хорошего специалиста от действительно ценного и незаменимого. Спойлер: дело не только в хард-скиллах 😉

Конечно, технические навыки? это фундамент. Kubernetes там, CI/CD, мониторинг — без этого никуда. Но чем дальше, тем больше работодатели и команды смотрят на то, что называется "софт-скиллы". И вот почему:

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

Еще один мастхэв — умение работать в команде. DevOps — это про коллаборацию, про стирание границ между "они" и "мы". Тут важно быть эмпатичным, уметь слушать, подстраиваться, находить общий язык с разными людьми. Без этого даже самый крутой технарь рискует остаться за бортом.

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

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

Так что если хотите стать незаменимым — инвестируйте в софт-скиллы. Как? Вот пара идей:

1️⃣ Записывайтесь на курсы и тренинги по коммуникации, публичным выступлениям, управлению конфликтами. Прокачивайтесь по Agile, Scrum, Kanban — пригодится в работе с командой.

2️⃣ Читайте нон-фикшн по психологии, лидерству, саморазвитию. Рекомендуем "7 навыков высокоэффективных людей", "Эмоциональный интеллект", "Психологию влияния". Бонус: будете блистать на обеде, цитируя умные книжки 😎

3️⃣ Практикуйтесь каждый день. Вызывайтесь проводить демо, брать на себя роль фасилитатора на планировании. Предлагайте менторство младшим коллегам. Инициируйте ретро по процессам. В общем, не стесняйтесь выходить из зоны комфорта.

4️⃣ Попробуйте что-то новое. Запишитесь на курс по публичным выступлениям, актерскому мастерству, импров-театру. Да хоть на сальсу, если приглянется! Новые навыки и знакомства всегда освежают и дают неожиданные инсайты.

Главное: не забывайте про баланс. Технические навыки это базис, без них никуда. Но софт-скиллы — это то, что отличает профессионала от просто исполнителя. Нужно и то, и другое в разумных пропорциях.

Так что вперед, коллеги, прокачиваться и в хардах, и в софтах! Станьте незаменимыми, сделайте так, чтобы за вас дрались на HR-рынке 😏

А если у вас есть свои лайфхаки по прокачке софт-скиллов - делитесь в комментах, не томите! Вместе мы - сила, одними техническими навыками DevOps не построишь.

На этом у нас все, увидимся в следующих постах! Следите за апдейтами и не дайте хаосу внешнего мира нарушить ваш внутренний дзен 🙏

🏴‍☠️ @happy_devops

DevOps в эпоху нестабильности: как не просто выживать, а побеждать

Коллеги, все мы знаем, что мир IT сейчас напоминает американские горки — крутые виражи, непредсказуемые взлеты и падения. Особенно достается нам, DevOps-инженерам. Не успели стабилизировать один процесс, хоп, новый фреймворк подъехал! Только-только команда сработалась, бац, реорганизация! А уж про смену приоритетов и срочные таски вообще молчим, да?

Но знаете что? Нестабильность — это не приговор, а возможность проявить себя. Показать, что мы не просто выполняем задачи, а гибко адаптируемся, растем над собой и ведем за собой команду. Как говорится, если жизнь дает вам лимоны — сделайте лимонад, добавьте лёд и листик мяты 🍋😎

Так что вот вам наши лайфхаки, как в этом хаосе не просто выживать, а побеждать:

1️⃣ Принимайте изменения как данность. Не ворчите "раньше трава была зеленее", а ищите плюсы. Новая технология? Отлично, будет что изучить и чем удивить на собесе! Новые процессы? Супер, покажите, как их оптимизировать!

2️⃣ Фокусируйтесь на главном. В приоритете — стабильность продакшена, остальное по возможности. Выработайте с командой критерии: что must have, что nice to have. И всегда держите руку на пульсе бизнес-метрик.

3️⃣ Автоматизируйте рутину. Если приходится делать что-то регулярно и муторно — пишите скрипт, настраивайте алерты, интегрируйте с мониторингом. Не только себе жизнь облегчаете, но и время освобождаете на важные задачи и личное развитие.

4️⃣ Инвестируйте в отношения. В эпоху удаленки и текучки особенно ценны связи и доверие в команде. Будьте проактивны, интересуйтесь коллегами не только по рабочим вопросам. Поддерживайте, делитесь знаниями, отмечайте успехи. Глядишь, и сами не заметите, как станете Dream Team 🤜🤛

5️⃣ Качайте софт-скиллы. Коммуникации, эмпатия, управление стрессом — без этого сейчас никуда. Прокачивайтесь на курсах, тренингах, в общении. Эмоциональный интеллект и умение ладить с людьми — ваш джокер в колоде.

6️⃣ Заботьтесь о себе. Высыпайтесь, питайтесь нормально, гуляйте на свежем воздухе. Находите время на хобби и отдых мозга. Помните: вы — не функция, а прежде всего люди. Выгоревший, загнанный специалист — не профессионал, а ходячая проблема.

В общем, коллеги, нестабильность — это наша новая норма. Но в наших силах обратить ее себе на пользу. Быть волной, а не щепкой в ее потоке. Помогать друг другу, расти и становиться сильнее 💪

Это непросто, но оно того стоит. В конце концов, разве вы пошли в DevOps, чтобы было легко и скучно? То-то же!

Чем больше хаоса снаружи - тем важнее сохранять порядок внутри. Как в коде, так и в мыслях 😏

Расскажите в комментах, как вы справляетесь с нестабильностью и неопределенностью. А мы пойдем пилить наш Flux Capacitor для прогнозирования будущего 🔮😅

И ставьте реакции, друзья, ставьте! Нам важно ваше мнение и важно по-настоящему

🏴‍☠️ @happy_devops

⏩ Bloomberg: Apple’s New iPad Mini Highlights the Company’s Secret AI Advantage

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

Судя по всему, первые плоды Apple Intelligence особо не впечатляют. Новые фичи для iPad mini обещают лишь к концу года, да и то по чайной ложке. А уж сравнивать Siri с нашумевшим ChatGPT от OpenAI и вовсе неловко — и по точности ответов, и по широте кругозора чат-бот Альтмана впереди на порядок.

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

⏩ Wall Street Journal: Wanted: Weekend Warriors in Tech

Пентагон решил пополнить ряды вооруженных сил США самыми ценными кадрами - IT-специалистами. Теперь директора по технологиям и другие ТОПы из мира хайтека смогут примерить военную форму и получить офицерское звание.

Правда, воевать их никто не заставит (пока). Речь идет о статусе резервистов, которых будут привлекать для краткосрочных проектов в сфере кибербезопасности, анализа данных и других модных направлений.

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

В общем, cкоро в американском IT вместо пиццы и фрисби в офисе будут полевые учения и марш-броски. Но зато можно будет козырять званием майора или капитана. Такие вот карьерные перспективы в новом дивном мире!

⏩ Основатель Флибусты принял решение добровольно уйти из жизни

Грустная новость без выводов. Основатель знаменитой Флибусты принял решение принять смертельную инъекцию. RIP и спасибо за труд. Насколько нам известно, Флибусту подхватили и продолжат поддерживать. По понятным причинам, личности этих прекрасных людей остаются в тайне

#новости_по_пятницам

🏴‍☠️ @happy_devops

DevOps — это не про инструменты, а про культуру. Как донести это до манагеров и не сойти с ума

Привет, друзья! Повторенье — мать ученья и сегодня в нашей повестке дня опять извечный холивар: что же такое DevOps на самом деле? Модный набор инструментов или всё-таки культура и образ мышления? Спойлер: мы топим за второе. Но как же донести эту мысль до манагеров, которые уже настроились "вот завтра поставим кубер и будем жить как боги"? Сейчас расскажем, а вы подтягивайтесь с попкорном и делитесь своими историями в комментах.

Начнем с того, что у многих сложилось впечатление, будто DevOps — это про автоматизацию и контейнеризацию. Поставил Docker, Kubernetes, настроил CI/CD и вуаля, ты уже в клубе любителей девопса. Но давайте будем честны: инструменты — это всего лишь верхушка айсберга. Да, они важны, да, без них сейчас никуда. Но ядро DevOps — это культура коллаборации, непрерывного улучшения и ответственности за продукт на всех этапах его жизненного цикла. И без слаженной командной работы и правильных процессов все эти дженкинсы-хелмы-кубернетисы — просто набор модных аббревиатур.

Так почему же этот месседж так сложно донести до менеджмента? Ну, во-первых, культура — штука неосязаемая и не всегда легко измеримая. Это вам не "вот отчет, сколько релизов мы сделали в этом квартале". Её нельзя потрогать, её сложно оценить в денежном эквиваленте. А во-вторых, внедрение DevOps-культуры — процесс долгий, местами болезненный и требующий серьёзных организационных изменений. Это вам не "давайте купим очередную недоплатформу и отчитаемся о диджитализации". Тут надо менять мышление, разрушать силосы, налаживать коммуникацию между отделами. А кому охота выходить из зоны комфорта и брать на себя дополнительную ответственность?

Так что да, убедить манагеров в том, что DevOps — это про людей и процессы, а не только про инструменты, это та ещё задачка. Но, как говорится, глаза боятся, а руки делают. И вот вам несколько советов, как подступиться к этой проблеме.

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

Во-вторых, образовывайте и объясняйте. Не стесняйтесь проводить доклады, писать статьи, делиться опытом. Рассказывайте о своих успехах и фейлах, приводите цифры и кейсы. Глядишь, и до топов дойдет, что DevOps - это не просто хайповое словечко, а реальный подход к формированию ценности.

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

Ну и наконец: будьте терпеливы и настойчивы. Да, внедрение DevOps-культуры — процесс не быстрый. Да, вам придется преодолевать сопротивление и косность мышления. Но оно того стоит, поверьте. Ведь в конечном итоге вы получите не только более эффективные процессы, но и более зрелую, ответственную и сплоченную команду. А с такой командой вам любые горы по плечу — хоть Kubernetes пилить, хоть на Марс лететь.

В общем, друзья, давайте не будем скатываться в инструментальщину и забывать о главном. DevOps — это в первую очередь про культуру, про людей, про общие цели и ценности. И только потом уже про контейнеры, пайплайны и прочие ништяки. Давайте нести эту мысль в массы, и рано или поздно до всех дойдет. А с вас истории о том, как вы переубеждали упертых менеджеров и какие подводные камни встречали на этом пути. Поделитесь в комментах, а мы пока пойдем перечитывать "Проект Феникс" и настраиваться на долгую битву за светлое DevOps-будущее!

🏴‍☠️ @happy_devops

Перешел из сисадминов в DevOps: нелегкий путь одного айтишника

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

Начнем с предыстории. Работал наш герой сисадмином в одной небольшой конторе. Всё как обычно: железки крутил, юзеров тихо ненавидел, начальству репортил. И так годика три в относительном комфорте и стабильности. Но в какой-то момент стало скучно и захотелось движухи. Тут-то и попалась ему на глаза модная DevOps-методология. Ну, думает, чем черт не шутит, пойду учиться и резюме обновлять.

Сказано — сделано. Закупился книжками, прошел пару онлайн-курсов, поднял на коленке стендик с докером и джейкинсом. В общем, прокачался до уровня "принеси-подай" и "кое-что слышал". И тут удача: в соседний отдел ищут джуна аж с двойным окладом. Принес резюме, поулыбался на собеседовании, показал pet-проект... и вот она, DevOps-позиция у него в кармане. Мечты сбываются!

Но, как говорится, бойтесь своих желаний. Первый месяц на новой работе вышел, мягко говоря, захватывающим. Объем новой инфы просто сносил крышу: Git, CI/CD, облака, мониторинг, логирование, Ansible, Terraform. Это мы ещё молчим про паттерны, архитектуры и прочие высокие материи. Хорошо хоть с коллегами повезло, подсказывали и не смеялись над тупыми вопросами.

Дальше больше. Как выяснилось, в "той" команде девопсы и разработчики не только на одном этаже сидели, но и в одних чатиках общались, и на одних митингах бывали. И вот это вот всё про "ответсвенность", "инициативу" и "профессиональный рост" оказалось не просто красивыми словами. Теперь от него требовалось не только сервера крутить, но и в код нырять, и архитектуру обсуждать, и даже с бизнесом болтать о фичах. Вот это поворот!

Сказать, что первое время наш герой был в некотором шоке — это ничего не сказать. Каждый день открывал для себя что-то новое, причем не всегда приятное. Хотели кластер Kubernetes развернуть, обнаружили, что сеть левая и всё плющит. Решили логирование централизовать, оказалось, что форматы у всех разные и парсить их одной регуляркой — та ещё морока. А уж когда дошло до написания первого Terraform-модуля, он чуть не поседел: это ж не баш-скрипт, тут думать надо!

Но знаете, что? Примерно через полгода этого бурного девопс-серфинга он понял, что оно того стоило. Да, было сложно, да, много раз хотелось все бросить и откатиться в сисадминство. Зато сейчас он может с гордостью сказать, что находится "на ты" со многими DevOps-инструментами и практиками. Нет, он не стал гуру, до сеньорства ещё пахать и пахать. Но он более-менее освоился, вник в процессы и даже начал сам предлагать идеи по улучшению. А ещё завёл много знакомств и полезных связей, как внутри компании, так и на всяческих внешних активностях, куда он, как девопс, начал часто попадать.

Так что, коллеги, если вы сомневаетесь насчет перехода из сисадминов в DevOps — не бойтесь. Да, будет страшно, да, будет сложно, да, порой будет хотеться все бросить. Но оно реально стоит усилий. Новый опыт, новые знакомства, профессиональный рост опять же. Главное, не стесняйтесь спрашивать, учиться на ошибках и держать нос по ветру. Ну и без чувства юмора в нашем деле никак.

Такие вот дела, друзья. Надеемся, эта история была полезна и интересна. А теперь традиционно зовем вас в комменты. У кого какой опыт перехода? Может, есть смешные истории или советы для новичков? Делитесь, не стесняйтесь. Давайте обсудим все прелести и гадости DevOps-жизни без купюр и цензуры. Поехали!

И не забывайте про реакции, нам важно понимать, насколько заходит контент

🏴‍☠️ @happy_devops

Как выжить DevOps-инженеру в большой корпорации: лайфхаки и советы от бывалых

Привет, DevOps-бойцы! Сегодня затронем больную для многих тему: как не сойти с ума, будучи DevOps-инженером в большой корпорации. Знаете эти бесконечные митинги, согласования, бюрократию и прочие радости энтерпрайза? Вот-вот, про них родимых и поговорим. Расскажем про опыт редакции, а вы дополняйте в комментах, глядишь, соберем хороший набор лайфхаков для новичков.

Первое, с чем сталкиваешься в корпе — это огромное количество стейкхолдеров. Каждый со своим интересом, и все хотят твоего внимания. Разработка требует релизов через день, безопасники хотят три уровня авторизации для любого чиха, а топ-менеджмент уже раз пять переспросил "когда уже будет готово?". И всем надо уметь разъяснить, успокоить и что-то пообещать. Наш совет: определите ключевых игроков, выстройте с ними доверительное общение и действуйте через них. Плюс учитесь находить компромиссы, а то утонете в бесконечных митингах.

Вторая напасть: легаси, легаси everywhere. Допотопные системы с колоссальным техдолгом, трехэтажные монолиты, про которые уже никто не помнит, как и зачем они работают. И вот это все надо как-то деплоить, мониторить и вообще поддерживать жизнь. Тут главное — определите, что можно относительно безболезненно зарефакторить, а что лучше не трогать. Проводите инкрементальные улучшения, интегрируйте с современными практиками, но без фанатизма. Лучше медленно, но верно, чем сломать все и получить проблемы с продакшеном.

Третий момент: в корпорации процессы превыше всего. На каждый чих по три согласования и пять подписей. Хочешь новый сервис поднять, изволь обоснование написать, архитектурный комитет пройти и со всеми утрясти. Как с этим бороться? Ну, во-первых, таки автоматизировать все, что можно. IaC наше все — инфра и конфиги в кодовом виде, деплой по кнопке, роллбеки автоматические. Меньше будет ручной работы — меньше согласований. Во-вторых, инвестируйте время в выстраивание отношений со смежниками. Глядишь, если по-человечески договоритесь, можно и про некоторые бюрократические формальности "забыть".

Ещё одна частая беда — мотивация и профессиональный рост. В корпорациях легко стать "винтиком" и закопаться в рутину. Годами пилить один и тот же проект, не видя особых перспектив, — то ещё удовольствие. Что делать? Ищите возможности дополнительного обучения — конференции, митапы, курсы. Не стесняйтесь проситься спикером, делиться знаниями с коллегами. Заводите знакомства в других отделах, присматривайтесь к открывающимся вакансиям. В общем, держите руку на пульсе и не давайте себе застаиваться.

Ну и напоследок: про отношения с коллегами. Корпорации — они разные, но политика и интриги есть почти везде. Кто-то тянет одеяло на себя, кто-то старается выслужиться перед начальством, а кто-то просто тихо сливает всю работу. Наш совет: не участвуйте в играх, будьте выше этого. Постройте личный бренд профессионала, который спокойно и надежно делает свою работу. Общайтесь со всеми ровно, делитесь знаниями, помогайте коллегам. Глядишь, и вам в нужный момент помогут.

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

Но хватит лирики, давайте к делу. Расскажите, как вы выживаете в энтерпрайзе? С какими граблями сталкивались, как разруливали ситуации? Может, есть какие-то хитрые лайфхаки или забавные истории? Делитесь в комментариях, вместе соберем базу знаний для тех, кто только начинает свой DevOps-путь в большой компании. Поехали!

🏴‍☠️ @happy_devops

Адекватный взгляд на DevOps: мифы и реальность

Коллеги, опять сегодня у нас на повестке дня святая корова — DevOps. Все уши уже прожужжали про то, какая это панацея от всех проблем и как она вознесет бизнес на небеса. Но давайте разберемся без лишнего хайпа, что там все-таки должно быть внутри? Что действительно работает в боевых условиях, а что остается красивыми слайдами на конференциях?

Главный миф, который всегда радует — DevOps это про то, чтобы натыкать модных тулов и радоваться жизни. Мол, закупили облако, поставили оркестраторы, замониторили все что шевелится — и готово, скоро будем жить как в раю. Но по факту прикручивание новых технологий — это как вишенка на торте. Сам торт — это люди, процессы и договоренности между командами. Без этой основы ваши контейнеры и кубернетесы будут просто красивыми (и дорогими) игрушками.

Кстати, раз уж заговорили о тулзах — еще один популярный миф, что без микросервисов, Kubernetes и иже с ними в DevOps делать нечего. На деле работать в этом стиле можно хоть со старым-добрым монолитом. Да, с ним сложнее, но можно, было бы желание. Глобальная цель — делать инкременты продукта быстро, часто и с хорошим качеством. А какими методами вы этого достигаете — уже дело десятое.

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

Двигаемся дальше. Расхожее мнение: внедрив DevOps, сразу получаем профит в виде скорости и новых фич. И бизнес счастлив, и пользователи. А на практике часто по первости получается с точностью до наоборот — скорость падает, потому что параллельно с фичами приходится не забывать про техдолг, строить пайплайны, нормальный мониторинг и так далее. Это нужно четко проговаривать на берегу, чтобы потом не было сюрпризов и разочарований.

И кстати, о бизнесе. Многие думают, что DevOps — это чисто техническая история, мол, дело инженерное. Но без вовлечения и поддержки менеджмента и заказчика вся эта затея обречена. Так что надо быть готовым значительную часть времени тратить на объяснения, выстраивание процессов и донесение ценностей до всех слоев компании.

Ну и напоследок) DevOps не волшебная пилюля от всех проблем. Да, он реально может дать буст по скорости и качеству, но только если фундамент уже относительно крепкий. Если у вас монструозный легаси, полное отсутствие тестов и архитектура а-ля "и так сойдет" — никакой DevOps не поможет. Сначала разгребайте базовые проблемы, а уже потом задумывайтесь о высоком.

Резюмируя: давайте смотреть на вещи трезво, отделяя зерна от плевел. Это не серебряная пуля, а серьезная методология со своими граблями и подводными камнями. Методология, требующая слаженной работы людей и процессов на всех уровнях. Но результат того стоит — более быстрые и качественные продукты, довольные пользователи и все такое. Так что дерзайте, но без фанатизма!

Делитесь в комментах своим опытом и мнением, и не забывайте про реакции, без них никуда

🏴‍☠️ @happy_devops

Домен .io скоро канет в Лету. Прощай, любимая игрушка стартаперов!

Ну что, гики и стартаперы, готовы попрощаться с любимой доменной зоной? Британия решила избавиться от островов Чагос, а вместе с ними — и от домена .io. И вот теперь все эти крутые Github.io, itch.io и прочие модные штучки скоро станут историей.

А ведь как красиво звучало: "Мы используем .io, потому что это input/output!". Ага, конечно. На самом деле вы просто выпендривались перед инвесторами. Но теперь придется искать новые способы показаться крутыми.

Самое забавное, что домен может исчезнуть быстрее, чем вы успеете сказать "блокчейн". IANA, ребята, которые заведуют доменами, не шутят — как только страна исчезает с карты, прощай и домен. Вспомните .su — до сих пор болтается в интернете, как призрак СССР.

Так что, дорогие владельцы .io доменов, начинайте паковать цифровые чемоданы. И в следующий раз, прежде чем выбирать модный домен, может, стоит открыть карту мира?

А теперь о грустном. Точнее, о российском.

Роскомнадзор решил, что Discord — это исчадие ада и заблокировал его. Причина? Да как обычно — "экстремизм", "терроризм" и прочая лабуда из методички.

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

И вот представьте картину: сидят где-то наши бойцы, пытаются координировать атаку, а тут — бац! — и Discord не работает. "Извините, товарищ генерал, мы не можем начать наступление — Роскомнадзор запретил".

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

Ну что, айтишники, готовы к новым приключениям в мире доменов и блокировок? Делитесь в комментах, как будете выкручиваться. Самому креативному решению — виртуальная медаль "За цифровое выживание в условиях, приближенных к боевым".

И не забывайте про реакции друзья! Обратная связь от вас дает нам силы работать!

#новости_по_пятницам

🏴‍☠️ @happy_devops

Культ личности в IT: когда харизма важнее кода

Ах, эти IT-гуру! Харизматичные, яркие, готовые свернуть горы одним взмахом клавиатуры. Прямо как Стив Джобс, только в свитере за 30 баксов с AliExpress. И ведь работает магия — инвесторы в экстазе, сотрудники готовы пахать 25 часов в сутки, а профильные СМИ захлебываются от восторга.

Но знаете, в чем проблема? Иногда за этим сияющим фасадом скрывается огромная черная дыра некомпетентности, готовая поглотить всю компанию.

Представьте: вы приходите в офис условного стартапа. Вас встречает энергичный CEO в кроссовках за косарь баксов. Он вещает о "революции в индустрии" и "парадигме блокчейн-AI-облачных вычислений". Звучит впечатляюще, не так ли? А теперь попросите его объяснить, как именно это работает. Готов поспорить, вы услышите набор модных словечек, за которыми скрывается... ничего.

И ведь таких примеров — пруд пруди. Помните историю Элизабет Холмс и Theranos? Или Адама Ньюмана из WeWork? Харизма на миллион, компетенций на копейку. Но инвесторы все равно несут деньги, сотрудники — свое время и силы. А потом — бац, и компания схлопывается, оставляя после себя выжженую землю и разбитые мечты.

Но самое страшное — это когда такой "визионер" начинает верить в собственную непогрешимость. "Я же гений, я не могу ошибаться!". И понеслась — сумасшедшие идеи, необдуманные решения, игнорирование мнения реальных экспертов. А любая критика воспринимается как личное оскорбление и происки врагов.

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

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

Может, пора уже повзрослеть? Начать ценить не громкие слова, а реальные дела и компетенции? Выбирать лидеров не по умению красиво говорить, а по способности создавать работающие продукты?

А что думаете вы? Сталкивались ли с такими харизматичными, но некомпетентными лидерами? Как отличить настоящего визионера от просто хорошего оратора?

Делитесь своими историями и мыслями в комментариях. Самые сочные кейсы получат виртуальный орден "За разоблачение культа личности в IT".

Ставьте реакции, поддержите нас лайком:
🙈 — если вы за харизму
🕊 — если вы за компетентность

Давайте посмотрим, чего в нашем сообществе больше!

🏴‍☠️ @happy_devops

ИИ vs менеджер: битва за корпоративный трон

Эй, менеджеры, как там ваше кресло? Удобно сидится? Наслаждайтесь, пока можете, потому что ИИ уже точит свои алгоритмические зубки на ваше место.

Представьте себе мир, где искусственный интеллект берет на себя все эти "невероятно сложные" задачи менеджера. Планирование спринтов? ИИ сделает это за долю секунды, учитывая все возможные риски и даже настроение команды после вчерашней попойки. Распределение задач? Легко! Причем без этих ваших "я думаю, Вася сегодня справится" — только чистая математика и анализ эффективности.

А как вам идея ИИ, проводящего стендапы? Никаких больше "ну, эээ, я вчера работал над таской, сегодня продолжу" — только четкие отчеты и реальный прогресс. И главное — никакого кофе в процессе!

Созвоны и встречи? ИИ организует их с такой эффективностью, что вы забудете о существовании лишних совещаний. Прощай, бесконечные обсуждения обсуждений!

Но самое прекрасное — это объективность. Никаких любимчиков, никакого "я считаю, что Петя поработал лучше". Только факты, цифры и реальные результаты. Представляете, какой это будет удар по офисной политике? Бедные интриганы останутся без работы!

Конечно, найдутся скептики, которые скажут: "Но ведь ИИ не может заменить человеческое общение, эмпатию, лидерство!". Ха! Погодите, пока нейросети научатся генерировать мотивирующие речи и корпоративные мемасики. Уверен, они справятся с этим не хуже среднестатистического менеджера.

Но не спешите паковать свои вещи, дорогие менеджеры. У вас все еще есть шанс! Например, вы можете начать изучать, как управлять этим самым ИИ. Кто знает, может быть, профессия "менеджер искусственного интеллекта" станет новым трендом?

А что думаете вы, уважаемые айтишники? Готовы ли вы доверить свою судьбу бездушной машине? Или все-таки предпочтете живого, пусть и не всегда компетентного, менеджера?

Делитесь своими мыслями в комментариях. Самые интересные идеи по спасению менеджеров от восстания машин получат виртуальную медальку "Защитник человечества".

И не забудьте поставить реакции!
🔥 — если вы за людей
🗿 — если вы уже на стороне ИИ.

Да начнется битва!

🏴‍☠️ @happy_devops

Меритократия в IT: сказка для наивных

Ах, эта прекрасная сказка о меритократии в IT! Мол, только твои скиллы имеют значение, а всё остальное — пустая болтовня. Ну-ну, расскажите это тем, кто годами пашет, а повышения получают "свои" ребята.

Давайте честно: в нашем "справедливом" мире айти карьерная лестница часто больше похожа на детские горки в парке аттракционов. Вроде и лезешь вверх, а в итоге съезжаешь туда, куда тебя направят.

🎭 Корпоративный театр: Где твой главный скилл — умение изображать бурную деятельность на совещаниях.

🤝 Нетворкинг über alles: Потому что важно не то, что ты знаешь, а кого ты знаешь. И кто знает тебя, конечно же.

🐘 Стадный инстинкт: Следуй за трендами, даже если они ведут тебя к обрыву. Главное — быть в тренде!

👅 Лизоблюдство 2.0: Теперь с AI и блокчейном! Потому что просто подлизываться уже не модно.

🎭 Шоу "Кто громче всех кричит CI/CD": Неважно, что ты делаешь, главное — делать это громко и с умным видом.

А вишенка на торте — это когда тебя обходит чувак, единственная суперспособность которого — уметь красиво рассказывать о своих достижениях (которых, кстати, нет).

Но эй, не всё так плохо! Иногда, в редкие моменты просветления, компании действительно ценят настоящих профи. Правда, эти моменты так же редки, как работающий с первого раза код.

А у вас как обстоят дела с этой "меритократией"? Поделитесь в комментах своими историями восхождения по карьерной лестнице. Или падения с неё — тоже сойдёт, посмеёмся вместе.

Не стесняйтесь ставить реакции, вы же помните, что мы их очень любим:
🔥 — если вы всё ещё верите в сказки
🤬 — если вас уже достала эта псевдомеритократия

🏴‍☠️ @happy_devops

Продуктивность разработчиков: когда цифры врут

Друзья, давайте на минутку представим идеальный мир. Мир, где продуктивность разработчиков можно измерить одной простой метрикой. Где руководители радостно потирают руки, глядя на графики, уверенно ползущие вверх. Красота, правда?

А теперь возвращаемся в реальность. Исследовательская команда Google, похоже, решила разрушить эту прекрасную иллюзию. И знаете что? У них это чертовски хорошо получилось.

Оказывается, разработчики — это люди. Шок! Сенсация! Кто бы мог подумать? Но если серьезно, то об этом простом факте часто забывают. Мы так привыкли думать о программистах как о живых компиляторах, что забываем об их человеческой сущности. А ведь это ключ к пониманию продуктивности.

Но подождите, есть еще кое-что. Разработка ПО — это не конвейер по штамповке кода. Это творческий процесс, сродни искусству. Только вместо краски и холста — алгоритмы и байты. И как измерить продуктивность Пикассо? Количеством мазков в минуту?

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

Но самое главное — необходимо помнить о человеческом факторе. Счастливый разработчик — продуктивный разработчик. Звучит как банальность, но сколько компаний реально следуют этому принципу?

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

В конце концов, разработка ПО — это марафон, а не спринт (хех, какая ирония😁). И победит в нем не тот, кто быстрее всех набирает код, а тот, кто сумеет создать среду, где талантливые люди смогут раскрыть свой потенциал.

Так что в следующий раз, когда вам захочется измерить продуктивность разработчиков, вспомните: за каждой строчкой кода стоит человек. Со своими мыслями, чувствами и, страшно подумать даже, личной жизнью. Может, пора начать измерять не только код, но и счастье?

Ссылка на статью: A Human-Centered Approach to Developer Productivity

А как у вас обстоят дела с нормальной продуктивностью, не всратой? Делитесь своими мыслями в комментариях. 👇
Кто знает, может вместе мы найдем ту самую волшебную формулу счастья и эффективности?

🏴‍☠️ @happy_devops

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

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

Ваши реакции как сахарочек для нас🤗 Ставьте огонечки, пишите комментарии, будем тащить формат в жизнь!

Live stream finished (1 hour)

Live stream scheduled for Oct 11 at 17:00

Live stream started

А я хочу напомнить, что сегодня в 20:00 MSK на нашем канале состоится стрим с Катей Лысенко

Поговорим про аджайл, про культуру и про высокоэффективные команды

Ждем всех!

А вот и новая серия "Игры престолов" в IT-мире! Только вместо драконов у нас HR-менеджеры, а вместо мечей — уведомления об увольнении.

Смотрите, как изящно ABBYY решила вопрос с "неудобными" сотрудниками. Прям как в анекдоте: хотели как лучше, а получилось... ну, вы поняли. "Перенос разработки в другой регион" — это ж надо было так креативно назвать массовые увольнения! Интересно, в какой регион они переносят — в страну розовых пони и бесконечных бюджетов?

А VK? О, эти ребята вообще превзошли сами себя! С одной стороны, устроили свою версию "Игры в кальмара" для сотрудников. С другой — тут же открыли двери для беженцев из ABBYY. Прям как добрый дядюшка, который одной рукой раздает подзатыльники, а другой — конфетки.

Особенно умиляет эта игра в "добрую" и "злую" корпорацию. VK типа такие: "Ой, смотрите, какие мы хорошие, мы спасаем бедных уволенных!" А то, что у самих только что прошла волна сокращений — ну так это ж другое, правда?

Знаете, что самое забавное? Пока эти корпоративные гиганты играют в свои игры, реальные таланты просто уходят. Куда? Да куда угодно — в стартапы, во фриланс, в другие страны. Потому что кому охота быть пешкой в чужой игре престолов?

Ладно, хватит ехидничать. Давайте по существу. Кто из вас уже почувствовал на себе эту корпоративную карусель? Может, кто-то недавно "оптимизировался" или, наоборот, оказался в роли спасательного круга для "утопающих" коллег?

Бросьте сюда свои две копейки. Интересно услышать, как вы оцениваете эти кульбиты на рынке труда. Может, у кого-то есть инсайды или прогнозы на будущее?

Не стесняйтесь, вываливайте всё как есть. Авось, вместе разберемся, куда ветер дует и чего ждать дальше в нашем IT-цирке.

#новости_по_пятницам

🏴‍☠️ @happy_devops

Эффективный менеджмент: искусство выглядеть занятым 24/7

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

Но ведь главное — это процесс, верно? Кому нужны эти скучные результаты, когда можно весь день играть в увлекательную игру "я очень занят, не беспокоить"?

Начинается все, конечно же, с утреннего ритуала под кодовым названием "я вам не проснулся". Главное — вовремя нажать кнопку "присоединиться к звонку", а там уже неважно, что ты в этот момент досматриваешь десятый сон.

Дальше — больше. День напролет мы скачем от встречи к встрече, словно в каком-то сюрреалистичном марафоне бессмысленности. Обсуждаем вчерашние обсуждения, планируем будущие планирования и, конечно же, align'имся по поводу alignment'а.

А как вам этот шедевр — назначить встречу, чтобы обсудить, нужна ли нам эта встреча? Или, может, отправить e-mail с вопросом "вы получили мой предыдущий e-mail?". Вот оно, высшее мастерство офисного джедая!

Но самое прекрасное начинается ближе к вечеру. Когда все задачи успешно отложены на завтра, наступает время для самого важного — рассказать всем, как сильно ты устал и как много работал. Желательно сделать это в соцсетях, снабдив пост хештегом #трудовыебудни.

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

А вы как, коллеги? Уже освоили высшее искусство имитации бурной деятельности? Или все еще по старинке пытаетесь реально работать? Делитесь в комментариях своими лайфхаками по эффективному просиранию рабочего времени. Кто знает, может, именно ваш метод станет новым трендом в мире корпоративного абсурда!

🏴‍☠️ @happy_devops

Друзья! Я тут набрасываю про аджайл всякое, но это все буковки) А давайте поговорим вживую!

Мы тут поговорили кулуарно на все теже темы с замечательной Катей Лысенко! Вы ее можете знать как спикера многих топовых конференций типа Хайлоада, Девопсконф и Тимлидконф, а также автора канала "ITKatya: культурные паттерны в IT"

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

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

Добавляйте в календарики! Пятница, 20.00 MSK, встречаемся прямо здесь) Будет интересно!

🏴‍☠️ @happy_devops

Кризис среднего звена: почему талантливые разработчики становятся посредственными менеджерами

Знаете эту историю? Берут крутого разраба, который может с закрытыми глазами написать микросервис и развернуть его в проде среди ночи. Дают ему команду, красивый титул и... через полгода имеем посредственного менеджера, который путается в Jira и не может внятно провести стендап.

"Как же так?" — удивляется руководство. А вот так.

Давайте разберем по пунктам это феерическое превращение:

Компания: "У тебя отлично получается писать код, значит, и людьми управлять сможешь!" Логика уровня: "Ты же умеешь водить машину, значит, и самолетом управлять сможешь!"

Разработчик: "Ну, я теперь типа менеджер, значит, надо... менеджерить?" И начинается: бесконечные митинги, таблички в экселе, и обязательное "я занят, у меня важные дела!"

Команда: "А где тот крутой разраб, который реально помогал решать проблемы?" А нету его. Теперь есть недоманагер, который знает (и знает ли?🤔) теорию процессов, но не может подсказать, почему билд падает.

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

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

Вот вам суровая правда жизни:
🔘 Умение писать крутой код никак не коррелирует с умением управлять людьми
🔘 Технический бэкграунд важен, но это не единственное, что нужно менеджеру
🔘 Быть тимлидом — это не "больше не кодить, а ходить на встречи"

И вот что действительно обидно: мы теряем отличных технарей, загоняя их в менеджерские позиции, потому что "надо расти". А может, не надо? Может, стоит дать людям расти в том, в чем они реально круты?

Что делать?
🔘 Хватит уже считать менеджмент единственным путем карьерного роста
🔘 Давайте признаем, что технический трек не менее важен, чем управленческий
🔘 И да, не каждому крутому разработчику нужно становиться менеджером

А у вас есть истории превращения технарей в менеджеров? Поделитесь в комментариях, посмеемся или поплачем вместе. Или может кто-то из менеджеров признается, что скучает по коду больше, чем по бесконечным встречам?

P.S. Если вы технарь и вам предлагают стать менеджером — дважды подумайте. А если вы руководитель и хотите продвинуть хорошего разраба — трижды подумайте. Иногда лучше оставить все как есть, чем создать еще одну адскую машину Голдберга, только теперь в менеджменте.

🏴‍☠️ @happy_devops

Как объяснить менеджеру, что его любимый Agile — это не волшебная таблетка

О, этот сладкий момент, когда ваш менеджер возвращается с очередной конференции, глаза горят, а в руках — новая библия под названием "Agile для чайников". И тут начинается...

"Ребята, теперь мы будем agile!" — торжественно объявляет он, словно открыл второе пришествие. А ты сидишь и думаешь: "Блин, опять двадцать пять".

Попробуй объяснить ему, что Agile — это не волшебная кнопка "сделать все хорошо". Это как фитнес-браслет для того, кто не вылезает с дивана. Прикольная штука, модная, но пока зад не поднимешь — результата не будет.

А еще попробуй донести, что "быть agile" и "делать скрам" — это не одно и то же. Что толку от ежедневных стендапов, если половина команды в них видит только возможность поспать стоя?

Или как насчет спринтов? Отличная штука, если ты не пытаешься впихнуть в двухнедельный спринт работы на квартал. "Но мы же гибкие!" — скажет менеджер. Ага, гибкие. Только почему-то эта гибкость всегда в сторону "впихнуть невпихуемое", а не "давайте сделаем меньше, но качественнее".

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

Самое смешное, что многие так и не понимают главного: Agile — это прежде всего про людей и взаимодействие, а не про артефакты и церемонии. Можно хоть обклеиться стикерами с головы до ног и переименовать все встречи в "скрамы", но если команда не умеет общаться и договариваться — толку не будет.

Так что в следующий раз, когда ваш менеджер прибежит с горящими глазами и новой agile-методичкой, сделайте глубокий вдох и спросите его: "А что конкретно мы хотим улучшить?". Потому что Agile — это не волшебная таблетка. Это тяжелая работа над собой и процессами. И да, иногда это больно.

А у вас как обстоят дела с Agile? Уже научились отличать реальную гибкость от очередной управленческой моды? Или все еще верите, что очередной фреймворк спасет вас от всех бед? Поделитесь в комментариях, посмеемся вместе над нашими agile-граблями.

🏴‍☠️ @happy_devops

Токсичная продуктивность🤬

Продуктивность — это как наркотик. Чем больше ты ее пробуешь, тем сильнее подсаживаешься. И тут начинается чехарда: надо больше, быстрее, эффективнее. Но знаете в чем прикол? Всратая продуктивность хуже, чем ее отсутствие вообще

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

И вот в один прекрасный момент смотришь на весь этот продуктивити порн и думаешь — нахрена? Вместо того, чтобы просто делать свое дело, ты возишься со всем этим. Не, ну а че, модно же! 🙄

Начинаешь работать как бешеная белка в колесе без перерывов и отдыха. С утра до вечера, по выходным и в отпуске думаешь только о том, как бы еще что-то зафигачить и оптимизировать. И ладно бы это давало годный результат, так фигушки!

В какой-то момент количество задач превращается в качество бреда. Ты уже и не помнишь, когда в последний раз нормально отдыхал, ел, спал, да просто жил. Мозги кипят на максималках, но КПД прям нулина. А все потому что ты в капкане токсичной продуктивности 🪤

И знаете что? К черту такую продуктивность! Работать надо в кайф. Если ты выжат как лимон и от одной мысли о работе трясет, то это полный абзац. Это выгорание и оно не лечится еще бОльшим количеством работы.

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

Профит!

А вы сталкивались с токсичной продуктивностью? Как справляетесь? Делитесь своими лайфхаками и опытом в комментах 👇

🏴‍☠️ @happy_devops

Яндекс-такси: техсбой или вас поимели, девочки?

Какая хорошая тема для пятницы🤗 В комментах на Хабре, традиционно, лютый треш и ебанина)

Короче, тут намедни у Яндекса случился какой-то дичайший зашквар. У людей бабки списывались многократно за всякую фигню, типа такси и покупок. Причем в диких количествах! У одного чувака подрезали аж 800к рублей!

Яндекс отнекивается, мол, это просто техническая ошибка, не парьтесь, но эксперты намекают, что в момент обновления прода их хакнули. Короче, видится какое-то палево и попахивает неприличными инсайдами

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

В общем, Яндекс конечно извинился, мол, так и так, косяк, бабки вернем, сервисы пашут как надо. Но эксперты советуют не привязывать к таким сервисам основные карты, а лучше вообще наликом платить. А то мало ли, опять какой "техсбой" случится, ага 😏 Да и бабло возвращают вручную, а если там кредитка была привязана? Кто-то мог попасть на неплохие такие проценты...

И давайте скажем спасибо ❤️🚖, что возвращают живые деньги, а не промокоды на такси. Хотя, вообще, по-хорошему за такое надо платить компенсацию

Как думаете, это реально техническая ошибка или Яндекс поимели хакеры? У кого какие мысли на этот счет? Пишите в комментах свои теории! 👇

🏴‍☠️ @happy_devops

Грешновато попинать DevOps и не пнуть аджайл, пробегая мимо😁

Помню, как мы на одном проекте внедряли Agile. Боже, сколько было энтузиазма! Доска с разноцветными стикерами, стендапы по утрам, ретроспективы... Казалось, вот оно — светлое будущее разработки. Гибкость, скорость, качество — всё будет!

А по факту что получили? Пародию на методологию.

Стендапы превратились в часовые совещания, где каждый считает своим долгом отчитаться о мельчайших деталях своего рабочего дня. Ретроспективы? Ха! Унылое перекладывание ответственности. "Я бы сделал, но вот коллега не доделал свою часть". Прекрасно, не правда ли?

Спринты? Не, не слышали. Зато есть бесконечная беготня и попытки впихнуть невпихуемое в дедлайны, которые с потолка взяли. "Гибкость", называется!

А уж про CI/CD вообще молчу. Типа, мы же Agile, значит, можем выкатывать в прод по сто раз на дню. И неважно, что половина фич не работает, а другая половина ломает то, что раньше работало.

Но самое удивительное знаете что? Все эти "Скрам-мастера" и "Agile-коучи". Они как грибы после дождя повылазили. И каждый, конечно, эксперт. Книжку прочитал — всё, гуру. А что в проекте происходит — неважно, главное церемонии соблюдать.

Короче, вся эта история с Agile превратилась в какой-то фарс. Ритуалы есть, а толку — чуть. Гибкость и эффективность просто потерялись по дороге.

Вот и думаю: может, ну его к черту, этот Agile? Вернуться к старому доброму водопаду? Или это уже слишком радикально? 🤔

А вы как считаете, коллеги? Agile ещё можно реанимировать или уже поздняк метаться?

🏴‍☠️ @happy_devops

DevOps умер? Да здравствует DevOps!

DevOps как культура провалился?

Помните, как нам впаривали эту сказку? DevOps — это не просто набор инструментов, это целая культура! Разработка и эксплуатация будут жить в мире и согласии, взявшись за ручки и распевая песенки про непрерывную интеграцию.

А что на деле? Классика жанра:
1. Разрабы по-прежнему кидают через забор свой неоттестированный высер.
2. Опсы в ужасе пытаются это говно запустить и не уронить продакшн.
3. Менеджеры носятся с этим "DevOps" как с писаной торбой, не понимая, что это вообще такое.

"Но у нас же теперь есть Kubernetes и пайплайны!" — кричат адепты. Ага, и что? Теперь у вас просто более сложный способ выстрелить себе в ногу.

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

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

Вместо того чтобы пытаться построить утопию, давайте лучше научимся:
🟣 Честно говорить о проблемах, а не замазывать их очередным слоем абстракции
🟣 Реально понимать, зачем нам нужен тот или иной инструмент
🟣 Прекратить гнаться за каждым модным словечком в мире DevOps

Может, тогда мы наконец начнем делать то, ради чего всё это затевалось — создавать и поддерживать работающие системы, а не играть в культурную революцию.

А вы как думаете? Реально ли еще спасти эту шайку-лейку под названием "DevOps-культура", или пора признать поражение и двигаться дальше? Делитесь в комментариях, почему у вас всё получилось (ха-ха) или почему всё пошло по известному адресу. Не скупитесь на реакции, кидайте какашки, если не согласны. Вы — представители индустрии, мы говорим с вами о том, что чувствуем и хотим услышать, что чувствуете вы

🏴‍☠️ @happy_devops