Перетащил на второй гравитрон пару старых кластеров.
Результат пока выглядит ок.
Предыдущие дни график был практически идентичен, а тут, при смене типа инстанса, словно и нагрузка на ЦПУ стала ниже.
Посмотрим как дальше будет это работать.
Экономия ~$73 доллара в месяц за один инстанс(в кластере их несколько).
#AWS #CostOptimization
Результат пока выглядит ок.
Предыдущие дни график был практически идентичен, а тут, при смене типа инстанса, словно и нагрузка на ЦПУ стала ниже.
Посмотрим как дальше будет это работать.
Экономия ~$73 доллара в месяц за один инстанс(в кластере их несколько).
#AWS #CostOptimization
👍7
Использовать CloudWatch Alerts это достаточная большая боль, если мы говорим про IaC.
Неблагодарная задача.
Нет нормальной поддержки циклов, автодискавери и фильтрации.
* все примеры ниже без модулей, без костылей, без новой графаны, чистый терраформ и ямлописаки
Например у вас есть AWS Redis.
Банально с одним шардом для двух нод вам надо сделать буквально следующее:
Это лишь один шард, всего две ноды.
Помножить на существующие 4 кластера + 3 окружения итого у нас сотни строчек.
Потом это улетает в SNS, там, скорее всего на Lambda, оттуда скрипты питона на ваш Slack.
Прямо скажем неудобно.
Могу предложить решение лучше:
если у вас используется Alertmanager и AWS EKS(Kubernetes), то заметно удобнее держать его там.
Установка клаудвоч экспортера(разово):
Конфиг клаудвоч экспортёра:
В данном примере показаны различные вариации использования.
Так же научите(разово) собирать метрики от вашего прометиуса/виктории метрикс
#AWS
Неблагодарная задача.
Нет нормальной поддержки циклов, автодискавери и фильтрации.
* все примеры ниже без модулей, без костылей, без новой графаны, чистый терраформ и ямлописаки
Например у вас есть AWS Redis.
Банально с одним шардом для двух нод вам надо сделать буквально следующее:
# Alarm for Primary Node
resource "aws_cloudwatch_metric_alarm" "redis_cpu_primary" {
alarm_name = "${var.project_prefix}-${var.environment}-redis-cpu-primary"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = "300"
metric_name = "CPUUtilization"
namespace = "AWS/ElastiCache"
period = "60"
statistic = "Average"
threshold = "80"
alarm_description = "Redis CPU utilization is too high on primary node"
alarm_actions = ["arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-health-notification"]
ok_actions = ["arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-health-notification"]
dimensions = {
CacheClusterId = "${aws_elasticache_replication_group.******.id}-001"
}
}
# Alarm for Replica Node
resource "aws_cloudwatch_metric_alarm" "redis_cpu_replica" {
alarm_name = "${var.project_prefix}-${var.environment}-redis-cpu-replica"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = "300"
metric_name = "CPUUtilization"
namespace = "AWS/ElastiCache"
period = "60"
statistic = "Average"
threshold = "80"
alarm_description = "Redis CPU utilization is too high on replica node"
alarm_actions = ["arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-health-notification"]
ok_actions = ["arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-health-notification"]
dimensions = {
CacheClusterId = "${aws_elasticache_replication_group.******.id}-002"
}
}
Это лишь один шард, всего две ноды.
Помножить на существующие 4 кластера + 3 окружения итого у нас сотни строчек.
Потом это улетает в SNS, там, скорее всего на Lambda, оттуда скрипты питона на ваш Slack.
Прямо скажем неудобно.
Могу предложить решение лучше:
если у вас используется Alertmanager и AWS EKS(Kubernetes), то заметно удобнее держать его там.
Установка клаудвоч экспортера(разово):
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm upgrade cloudwatch-exporter prometheus-community/prometheus-cloudwatch-exporter \
--install \
--version 0.25.0 \
--namespace monitoring \
--set aws.aws_access_key_id="${{ secrets.AWS_ACCESS_KEY_ID }}" \
--set aws.aws_secret_access_key="${{ secrets.AWS_SECRET_ACCESS_KEY }}" \
--values=EKS/cloudwatch-values.yaml
Конфиг клаудвоч экспортёра:
config: |-
region: us-east-1
period_seconds: 30
delay_seconds: 30
metrics:
- aws_namespace: AWS/RDS
aws_metric_name: CPUUtilization
aws_dimensions: [DBInstanceIdentifier]
aws_dimension_select_regex:
DBInstanceIdentifier: [".*production.*"]
aws_statistics: [Average]
- aws_namespace: AWS/SQS
aws_metric_name: ApproximateNumberOfMessagesVisible
aws_dimensions: [QueueName]
aws_dimension_select_regex:
QueueName: [".*production.*"]
aws_statistics: [Sum]
- aws_namespace: AWS/ES
aws_metric_name: FreeStorageSpace
period_seconds: 60
aws_dimensions: [DomainName, ClientId, NodeId]
aws_statistics: [Minimum]
- aws_namespace: AWS/ElastiCache
aws_metric_name: CPUUtilization
period_seconds: 60
aws_dimensions: [CacheClusterId]
aws_statistics: [Average]
В данном примере показаны различные вариации использования.
Так же научите(разово) собирать метрики от вашего прометиуса/виктории метрикс
- job_name: 'cloudwatch-exporter'
scrape_interval: 30s
static_configs:
- targets: ['cloudwatch-exporter-prometheus-cloudwatch-exporter.monitoring.svc.cluster.local:9106']
#AWS
✍1
Всё, метрики от клаудвоча в вашем прометиусе.
Можете создавать любые алёрты.
Например вот так для редиса:
или для RDS:
❤️Profit!
Всё! Больше ничего делать не надо!
Сколько бы вы потом не создали сотен и тысяч SQS/Redis/RDS - вам не надо для каждого из них писать отдельный алёрт!
То есть мы ну вообще никак не завязаны на конкретных инстансах или нодах!
Просто один раз установка экспортёра, один раз внести сбор метрик для прометиуса(если нет автодискавери) и добавить демешны/фильтры.
⚠️ВАЖНО
Важно понимать, что каждый запрос от клаудвоч экспортёра до клаудвоча это деньги.
- нужно собирать метрики не часто, чтобы не чарджить в большую сумму
- можно фильтровать(в конфиге пример с production)
- нужно собирать ровно то, что вам нужно, например только cpu usage average, min/max нам для самого алёрта не надо
- тайминги надо выставить для вас - чтобы не очень часто, чтобы много платить, но чтобы и не слишком редко - тогда вы будете поздно получать алёрты
#AWS
Можете создавать любые алёрты.
Например вот так для редиса:
- alert: REDIS_HIGH_CPU_USAGE
expr: aws_elasticache_cpuutilization_average > 80
for: 5m
labels:
severity: critical
emoji: 🔥
annotations:
summary: '`{{ $labels.cacheclusterid }}` is using {{ $value }}% of CPU. <https://****.grafana-workspace.us-east-1.amazonaws.com/d/AWSERedis/aws-elasticache-redis?var-cacheclusterid={{ $labels.cacheclusterid }}|Dashboard> | <https://****.pagerduty.com/incidents|PD>'
или для RDS:
- alert: RDS_HIGH_CPU_USAGE
expr: round(avg_over_time(aws_rds_cpuutilization_average[5m]), 0.01) > 80
for: 5m
labels:
severity: critical
emoji: 🔥
annotations:
summary: '`{{ $labels.dbinstance_identifier }}` is using {{ $value }}% of CPU. <https://****.grafana-workspace.us-east-1.amazonaws.com/d/AWSRDSdbi/aws-rds?var-dbinstanceidentifier={{ $labels.dbinstance_identifier }}|Dashboard> | <https://***.pagerduty.com/incidents|PD>'
❤️Profit!
Всё! Больше ничего делать не надо!
Сколько бы вы потом не создали сотен и тысяч SQS/Redis/RDS - вам не надо для каждого из них писать отдельный алёрт!
То есть мы ну вообще никак не завязаны на конкретных инстансах или нодах!
Просто один раз установка экспортёра, один раз внести сбор метрик для прометиуса(если нет автодискавери) и добавить демешны/фильтры.
⚠️ВАЖНО
Важно понимать, что каждый запрос от клаудвоч экспортёра до клаудвоча это деньги.
- нужно собирать метрики не часто, чтобы не чарджить в большую сумму
- можно фильтровать(в конфиге пример с production)
- нужно собирать ровно то, что вам нужно, например только cpu usage average, min/max нам для самого алёрта не надо
- тайминги надо выставить для вас - чтобы не очень часто, чтобы много платить, но чтобы и не слишком редко - тогда вы будете поздно получать алёрты
#AWS
🤩2
Почти год назад я ввязался в поддержку одного небольшого проекта.
Признаюсь и я, и команда из этого проекта были откровенно слабыми.
Я категорически слабо разбирался в базах данных, тюнинге, а на проекте никто не понимал что происходит.
База "тупила", клиенты были недовольны, никто не понимал куда копать.
Мы, словно угля в топку, накидывали неделя за неделей ресурсами всё выше и выше, лишь бы поезд ехал, но все понимали, что рано или поздно мы упрёмся в максимум типа инстанса и поезд остановится.
Откровенно говоря я даже не понимал как вот это всё работает, замучав всех в русскоязычных чатах глупыми вопросами по БД перформансу.
Так или иначе я пришёл к мнению, что надо внедрять мониторинг и алёртинг базы данных.
- Мы научились готовить PMM(расширенный бесплатный аналог AWS Performance Insights).
Он нам показал исторически на графиках куча мест, где у нас было сделано не оптимально(селекты, делиты и так далее).
- Мы научились мониторить стандартные метрики БД.
CPU usage, memory free/usage и другие системные ресурсы.
- Этого было мало, мы научились мониторить и алёртить сложные запросы.
Мне пришлось нырнуть дальше и у нас появились борды с MySQL slow query и алёртинг на их.
На правах внезапного репоста этого блога продублирую ссылку на свою статью, как мониторить/алёртить
https://medium.com/@kruchkov.alexandr/monitoring-and-alerting-for-slow-logs-in-amazon-rds-12dd048e16db
* Помню, что медиум это для многих неудобно, но я уже не вспомню зачем я публикую заметки именно там.
#AWS #RDS
Признаюсь и я, и команда из этого проекта были откровенно слабыми.
Я категорически слабо разбирался в базах данных, тюнинге, а на проекте никто не понимал что происходит.
База "тупила", клиенты были недовольны, никто не понимал куда копать.
Мы, словно угля в топку, накидывали неделя за неделей ресурсами всё выше и выше, лишь бы поезд ехал, но все понимали, что рано или поздно мы упрёмся в максимум типа инстанса и поезд остановится.
Откровенно говоря я даже не понимал как вот это всё работает, замучав всех в русскоязычных чатах глупыми вопросами по БД перформансу.
Так или иначе я пришёл к мнению, что надо внедрять мониторинг и алёртинг базы данных.
- Мы научились готовить PMM(расширенный бесплатный аналог AWS Performance Insights).
Он нам показал исторически на графиках куча мест, где у нас было сделано не оптимально(селекты, делиты и так далее).
- Мы научились мониторить стандартные метрики БД.
CPU usage, memory free/usage и другие системные ресурсы.
- Этого было мало, мы научились мониторить и алёртить сложные запросы.
Мне пришлось нырнуть дальше и у нас появились борды с MySQL slow query и алёртинг на их.
На правах внезапного репоста этого блога продублирую ссылку на свою статью, как мониторить/алёртить
AWS RDS slow logs (8.0.mysql_aurora.3.06.0), которую я писал в 2024 году.https://medium.com/@kruchkov.alexandr/monitoring-and-alerting-for-slow-logs-in-amazon-rds-12dd048e16db
* Помню, что медиум это для многих неудобно, но я уже не вспомню зачем я публикую заметки именно там.
#AWS #RDS
🔥5👍1
Сейчас на этом проекте всё работает как часы, инстансы совсем не жирные, а у разработчиков даже есть дашборда, куда они бегут, получив алёрты (их несколько разных).
Получив алёрт, ребята самостоятельно анализируют запросы, которые роняют базу и тут же пилят пулл-реквесты с безжалостным выпиливанием таких косяков. Поезд едет дальше.
#AWS #RDS #MySQL
Получив алёрт, ребята самостоятельно анализируют запросы, которые роняют базу и тут же пилят пулл-реквесты с безжалостным выпиливанием таких косяков. Поезд едет дальше.
#AWS #RDS #MySQL
🔥5❤3👍1
Для последнего проекта для AWS EKS использовал AMI на базе
https://aws.amazon.com/bottlerocket/
Название амишки и версию в голове и коде не держу, смелости и дурости у меня много, так что у меня идёт latest (на самом деле там почти хардкод, просто выглядит пугающе). Сбоев не было никогда из-за последнего в ssm.
С точки зрения кода там просто:
Если пугает такое обновление версий, то можно залепить такое и обновлять раз в месяц/квартал вручную.
Стратегий у меня несколько:
- event-driven
- load-driven
Ноды готовы очень быстро. При тюнинге в основном секунд 15.
В самых худших кейсах 2 минут 24 секунды. Такое было раз 5 по наблюдениям.
Зависит от типа инстанса, региона и спот ли.
Например типичный сценарий. Есть сервис в десятках подов, кто читает SQS. Они разные и цели у них разные.
- всего 2 ноды, 0 подов с без рабочей нагрузки.
- прилетели тонны мессаджей в AWS SQS, секунд за 5-15 на бурст в 100000+ сообщений
- KEDA через 5 секунд после threshold поднимается пару десятков подов
- кластер-автоскейлер/карпентер (зависит от проекта) поднимает одну или несколько нод в нод группу.
* Кластер автоскейлер мгновенно триггерит, если видит, что не хватает ресурсов и хоть что-то в
- сами ноды на ботлрокете поднимаются секунд за 12-15, каждая из нод. то есть через 15 секунд в основном уже
- поды на новых нодах шедулятся, проходят 2 пробы(startup, readiness), ещё 8-15 секунд.
- приложение готово к работе и разбирает мессаджи в sqs (+20 секунд к таймингам, если на этой SQS long polling)
- после разбора sqs всё тушится к нулям через KEDA, чтобы не платить
Ради теста повторил, лог такой:
Как видно ноды очень быстро стартуют. Это самый главный плюс.
Почему
- крайне быстрый старт нод, основная причина
- чуть более удобная(для меня) кастомизация kubelet, хоть там и не любимый мной TOML
- ну а как же без пункта best-CV-project, надо и новые вещи изучать
#AWS #EKS #bottlerocket
bottlerocket.https://aws.amazon.com/bottlerocket/
Название амишки и версию в голове и коде не держу, смелости и дурости у меня много, так что у меня идёт latest (на самом деле там почти хардкод, просто выглядит пугающе). Сбоев не было никогда из-за последнего в ssm.
С точки зрения кода там просто:
locals {
aws_ami_name = "bottlerocket"
aws_ami_architecture = "x86_64"
aws_ami_type = "${upper(local.aws_ami_name)}_${local.aws_ami_architecture}"
}
data "aws_ssm_parameter" "eks_ami_image_version" {
name = "/aws/service/${local.aws_ami_name}/aws-k8s-${aws_eks_cluster.eks.version}/${local.aws_ami_architecture}/latest/image_version"
}
resource "aws_eks_node_group" "blue-green-group" {
...
ami_type = local.aws_ami_type
release_version = data.aws_ssm_parameter.eks_ami_image_version.value
...Если пугает такое обновление версий, то можно залепить такое и обновлять раз в месяц/квартал вручную.
lifecycle {
ignore_changes = [release_version]
...
}Стратегий у меня несколько:
- event-driven
- load-driven
Ноды готовы очень быстро. При тюнинге в основном секунд 15.
В самых худших кейсах 2 минут 24 секунды. Такое было раз 5 по наблюдениям.
Зависит от типа инстанса, региона и спот ли.
Например типичный сценарий. Есть сервис в десятках подов, кто читает SQS. Они разные и цели у них разные.
- всего 2 ноды, 0 подов с без рабочей нагрузки.
- прилетели тонны мессаджей в AWS SQS, секунд за 5-15 на бурст в 100000+ сообщений
- KEDA через 5 секунд после threshold поднимается пару десятков подов
- кластер-автоскейлер/карпентер (зависит от проекта) поднимает одну или несколько нод в нод группу.
* Кластер автоскейлер мгновенно триггерит, если видит, что не хватает ресурсов и хоть что-то в
Pending статусе из POD-ов- сами ноды на ботлрокете поднимаются секунд за 12-15, каждая из нод. то есть через 15 секунд в основном уже
ready.- поды на новых нодах шедулятся, проходят 2 пробы(startup, readiness), ещё 8-15 секунд.
- приложение готово к работе и разбирает мессаджи в sqs (+20 секунд к таймингам, если на этой SQS long polling)
- после разбора sqs всё тушится к нулям через KEDA, чтобы не платить
Ради теста повторил, лог такой:
ip-10-1-33-89.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 1s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 1s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 1s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 1s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 10s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal Ready <none> 13s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 5s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 10s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal Ready <none> 14s v1.30.5-eks-baa6d11
Как видно ноды очень быстро стартуют. Это самый главный плюс.
Почему
bottlerocket:- крайне быстрый старт нод, основная причина
- чуть более удобная(для меня) кастомизация kubelet, хоть там и не любимый мной TOML
#AWS #EKS #bottlerocket
🆒3❤1
Я ещё буду писать про bottlerocket для AWS EKS и, особенно, про его тюнинг, там много любопытного.
👍10
Мне уже двое написали про
Немного теории:
В Kubernetes существует два типа эвикции (выселения) подов:
- Kubernetes сначала посылает сигнал SIGTERM поду, давая ему время корректно завершить работу
- Pod получает grace period (период отсрочки) для завершения работы
- По умолчанию grace period составляет 30 секунд
Можно настроить через параметр
- Происходит немедленное удаление пода
- Pod получает сигнал SIGKILL
- Используется когда нужно срочно освободить ресурсы
Настраивается через параметр
Основные триггеры эвикции:
-
-
-
-
Пороговые значения можно задавать как в процентах, так и в абсолютных величинах (например, 100Mi для памяти).
Дефолтные значения ванильного k8s можете посмотреть тут:
https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/
Для
❕Выше была общая теория, ниже практика.
#AWS #EKS #bottlerocket
bottlerocket, так что не теряя времени, пока смелые духом не запустили это в прод, продолжу.Немного теории:
В Kubernetes существует два типа эвикции (выселения) подов:
Soft Eviction (Мягкое выселение):- Kubernetes сначала посылает сигнал SIGTERM поду, давая ему время корректно завершить работу
- Pod получает grace period (период отсрочки) для завершения работы
- По умолчанию grace period составляет 30 секунд
Можно настроить через параметр
--eviction-soft-grace-period /--eviction-softHard Eviction (Жёсткое выселение):- Происходит немедленное удаление пода
- Pod получает сигнал SIGKILL
- Используется когда нужно срочно освободить ресурсы
Настраивается через параметр
--eviction-hardОсновные триггеры эвикции:
-
memory.available: доступная память-
nodefs.available: место на диске ноды-
nodefs.inodesFree: свободные иноды-
imagefs.available: место для образов контейнеровПороговые значения можно задавать как в процентах, так и в абсолютных величинах (например, 100Mi для памяти).
Дефолтные значения ванильного k8s можете посмотреть тут:
https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/
Для
AL2023 вот такие дефолт значения:memory.available: "100Mi"
nodefs.available: "10%"
nodefs.inodesFree: "5%"
imagefs.available: "15%"
❕Выше была общая теория, ниже практика.
#AWS #EKS #bottlerocket
🤔1
У
Вы это можете проверить командой на ноде
Ну или же посмотреть в конфиге:
https://github.com/bottlerocket-os/bottlerocket/blob/1.20.x/packages/kubernetes-1.29/kubelet-kubeconfig
Там пусто.
Что же это значит?
Это значит, что по дефолту если у вас:
- под(ы) с эфемерным хранилищем сожрёт все место на ноде
- под(ы) без лимитов цпу сожрёт всё процессорное время на ноде
- под(ы) без лимитов памяти сожрёт всю память на ноде
- диск заполнится имаджами под(а/ов) и гарбадж коллектор не успеет отработать
Ваша нода умрёт. Системные компоненты перестанут работать, кублету не хватит памяти и нода умрёт.
Нода не защищена от неконтролируемых действий со стороны подов.
Давайте это исправим:
- создадим темплейт/конфиг
- внутри добавим нечто типа такого
- добавить этот конфиг через юзердату
Не буду описывать все параметры, они описаны тут:
https://bottlerocket.dev/en/os/1.20.x/api/settings/kubernetes/#eviction-hard
https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md#description-of-settings
Цифры можете брать из дефолта(выше писал), в моём примере цифры ровно под те требования, которые есть у меня в моим кластерам и приложениям. Не обязательно использовать все параметры, что есть в моём примере, можете только 4 параметра использовать.
* если вы хотите выдать доступ к вашим нодам, то в моем конфиге надо false поменять на true и дальше по инструкции
https://github.com/bottlerocket-os/bottlerocket?tab=readme-ov-file#control-container
#AWS #EKS #bottlerocket
bottlerocket нет дефолтных значений.Вы это можете проверить командой на ноде
apiclient -u /settings | jq
Ну или же посмотреть в конфиге:
https://github.com/bottlerocket-os/bottlerocket/blob/1.20.x/packages/kubernetes-1.29/kubelet-kubeconfig
Там пусто.
Что же это значит?
Это значит, что по дефолту если у вас:
- под(ы) с эфемерным хранилищем сожрёт все место на ноде
- под(ы) без лимитов цпу сожрёт всё процессорное время на ноде
- под(ы) без лимитов памяти сожрёт всю память на ноде
- диск заполнится имаджами под(а/ов) и гарбадж коллектор не успеет отработать
Ваша нода умрёт. Системные компоненты перестанут работать, кублету не хватит памяти и нода умрёт.
Нода не защищена от неконтролируемых действий со стороны подов.
Давайте это исправим:
- создадим темплейт/конфиг
bottlerocket.tpl в нашем репозитории- внутри добавим нечто типа такого
[settings.kubernetes]
api-server = "${endpoint}"
cluster-certificate = "${cluster_auth_base64}"
cluster-name = "${cluster_name}"
pod-pids-limit = 1024
image-gc-high-threshold-percent = 85
image-gc-low-threshold-percent = 80
container-log-max-files = 50
container-log-max-size = "100Mi"
[settings.kubernetes.system-reserved]
cpu = "200m"
ephemeral-storage = "1Gi"
memory = "1Gi"
[settings.kubernetes.kube-reserved]
memory = "893Mi"
[settings.kernel]
lockdown = "integrity"
[settings.host-containers.admin]
enabled = ${enable_admin_container}
[settings.host-containers.control]
enabled = ${enable_control_container}
[settings.kubernetes.eviction-hard]
"memory.available" = "1Gi"
"nodefs.available" = "20%"
"nodefs.inodesFree" = "5%"
"imagefs.available" = "15%"
[settings.kubernetes.eviction-soft]
"memory.available" = "10%"
[settings.kubernetes.eviction-soft-grace-period]
"memory.available" = "30s"
- добавить этот конфиг через юзердату
resource "aws_launch_template" "node-launch-template" {
...
user_data = base64encode(templatefile("${path.module}/../../templates/bottlerocket.tpl",
{
"cluster_name" = aws_eks_cluster.eks.name #обязательный параметр!!!
"endpoint" = aws_eks_cluster.eks.endpoint #обязательный параметр!!!
"cluster_auth_base64" = aws_eks_cluster.eks.certificate_authority[0].data #обязательный параметр!!!
"aws_region" = var.AWS_DEFAULT_REGION #обязательный параметр!!!
"enable_admin_container" = false
"enable_control_container" = true
}
))
}Не буду описывать все параметры, они описаны тут:
https://bottlerocket.dev/en/os/1.20.x/api/settings/kubernetes/#eviction-hard
https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md#description-of-settings
Цифры можете брать из дефолта(выше писал), в моём примере цифры ровно под те требования, которые есть у меня в моим кластерам и приложениям. Не обязательно использовать все параметры, что есть в моём примере, можете только 4 параметра использовать.
* если вы хотите выдать доступ к вашим нодам, то в моем конфиге надо false поменять на true и дальше по инструкции
https://github.com/bottlerocket-os/bottlerocket?tab=readme-ov-file#control-container
#AWS #EKS #bottlerocket
🤩2
Коллеги запилили фронтенд сервис для инфры. Тупо страничка с ссылками на инфра ресурсы с SSO авторизацией.
На скрине объединил вид нескольких вкладок для демо.
В нем сделаны ссылки на бОльшую часть инфры по окружениям.
Оказалось очень удобно переходить по линкам, чем помнить адреса на память или держать 100500 вкладок.
Для онбординга тоже топ.
Сорс выкладывать не буду - думаю любая AI вам за 5 минут нагенерит код тайпскрипта такого решения.
Просто поделился мелким удобством идеей.
На скрине объединил вид нескольких вкладок для демо.
В нем сделаны ссылки на бОльшую часть инфры по окружениям.
Оказалось очень удобно переходить по линкам, чем помнить адреса на память или держать 100500 вкладок.
Для онбординга тоже топ.
Сорс выкладывать не буду - думаю любая AI вам за 5 минут нагенерит код тайпскрипта такого решения.
Просто поделился мелким удобством идеей.
🔥4👍1
* старый репост
"Как я проетерял полдня, но понял что не всегда свежая версия это хорошая версия..."
Утомили постоянные
#terragrunt
"Как я проетерял полдня, но понял что не всегда свежая версия это хорошая версия..."
Switched terragrunt to version "0.72.3"
time terragrunt plan
Acquiring state lock. This may take a few moments...
No changes. Your infrastructure matches the configuration.
real 0m54.200s
user 0m28.351s
sys 0m2.390s
Switched terragrunt to version "0.54.15"
time terragrunt plan
Acquiring state lock. This may take a few moments...
No changes. Your infrastructure matches the configuration.
real 0m43.498s
user 0m31.284s
sys 0m4.366s
Switched terragrunt to version "0.56.0"
time terragrunt plan
Acquiring state lock. This may take a few moments...
No changes. Your infrastructure matches the configuration.
real 3m29.356s
user 2m27.303s
sys 0m14.885s
Утомили постоянные
circular dependency hell на terragrunt, но ничего не поделать, каждые 5-15 версий это говно вылезает, приходится просто подбирать вариант "и багов немного, и время выполнения не больше 50 секунд(по "эталонному" модулю).#terragrunt
🤔2
"Вернись обратно"
Именно такую фразу я сказал на стриме своему интерну и он, само собой, её ни черта не понял.
Да чего я выделываюсь, я бы и сам её не понял без контекста😅
Переключиться в предыдущую рабочую директорию
Переключиться на предыдущий контекст Kubernetes
Переключиться на предыдущий namespace в Kubernetes
Переключиться на предыдущую ветку в git
Возможно есть что-то ещё c похожим поведением, но я, в основном, использую только это в работе.
#devops #очевидное #вероятное
Именно такую фразу я сказал на стриме своему интерну и он, само собой, её ни черта не понял.
Да чего я выделываюсь, я бы и сам её не понял без контекста😅
Переключиться в предыдущую рабочую директорию
cd - Переключиться на предыдущий контекст Kubernetes
kubectx - Переключиться на предыдущий namespace в Kubernetes
kubens -Переключиться на предыдущую ветку в git
git checkout -Возможно есть что-то ещё c похожим поведением, но я, в основном, использую только это в работе.
#devops #очевидное #вероятное
👍10❤2
Не амазоном едины.
Айти развивается очень быстро.
Каждый день появляется много новых практик, инструментов, подходов и всё новое устаревает уже через пару лет.
Индустрия не успевает сама за собой.
Давайте поговорим о метриках.
У нас есть миллионы метрик.
Для нод, для кубера, для PV, для контейнеров, виртуальных машин и даже баз данных в кубере, для приложений.
Однако мы живём в современном мире гетерогенных сетей и несовершенстве
Те метрики и подходы, которые были в 2011 году, в 2019 году и, особенно, 2025 году, безнадёжно отстали и редко показывают актуальную информацию.
Пример.
для одного только
https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#standard-ssd-size
Штатные метрики есть, но они слишком убоги и отсталые:
- сколько осталось айнод
- сколько осталось места на диске(в нашем случае PV)
Как оперативно отслеживать нет ли где в кубернетисе ситуации, когда мы упираемся в предел по IOPS дискам?
PVC у нас несколько СОТЕН и десятки кластеров.
Везде разные классы и размеры.
Вручную прописывать это бред.
Штатно метрик у нас нет.
На помощь нам приходят
На стеке
ВМалёрт просто берёт правила алёртов и отправляет на ручку алёртменеджера.
У vmrule есть две функции:
- создавать
- создавать новые
То есть через
Или обогащать существущие метрики новыми лейблами.
Идея тут какая была:
- делаем матчинг между разными видами метрик(у них не матчатся лейблы)
- делаем ещё раз чтобы потом можно было матчить
- создаем матрицу "тип стораджа = максимальный IOPS для него"
- выводим новую метрику "текущий IOPS"
- выводим новую метрику "коэффициент IOPS" где 0 это 0%, а 1 это 100%.
Новую метрику можно использовать как для графиков в графане, так и для алёртов.
На базе подобного подхода мы НЕ зависим какой у нас тип сторадж класса, какой у нас размер PVC и так далее.
У нас есть матчинг POD-PVC-StorageClass-IOPS и мы просто готовую метрику получаем, а калькуляция уже внутри.
Например
И нам не важно какой там сторадж класс. мы просто знаем, что считаеся всё внутри Victoria metrics и мы просто на выходе получаем готовую метрику с лейблами (cluster namespace po etc) и мы дальше это где угодно используем:
- графана дашборды
- алёрты
❕Важно понимать, что это пока мой около MVP, в арифметике или логике могут быть мои ошибки, опечатки, неточности и в будущем я буду планировать это анализировать и актуализировать реальным данным.
Я могу по своему не знанию чего-то не учитывать и обязательно это поправлю в будущем.
#azure #metrics #victoriametrics
Айти развивается очень быстро.
Каждый день появляется много новых практик, инструментов, подходов и всё новое устаревает уже через пару лет.
Индустрия не успевает сама за собой.
Давайте поговорим о метриках.
У нас есть миллионы метрик.
Для нод, для кубера, для PV, для контейнеров, виртуальных машин и даже баз данных в кубере, для приложений.
Однако мы живём в современном мире гетерогенных сетей и несовершенстве
observability.Те метрики и подходы, которые были в 2011 году, в 2019 году и, особенно, 2025 году, безнадёжно отстали и редко показывают актуальную информацию.
Пример.
для одного только
Azure у нас есть целая матрица IOPS дисков, которая зависит от размера и сторадж класса + бёрстабл мод по времени.https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#standard-ssd-size
Штатные метрики есть, но они слишком убоги и отсталые:
- сколько осталось айнод
- сколько осталось места на диске(в нашем случае PV)
Как оперативно отслеживать нет ли где в кубернетисе ситуации, когда мы упираемся в предел по IOPS дискам?
PVC у нас несколько СОТЕН и десятки кластеров.
Везде разные классы и размеры.
Вручную прописывать это бред.
Штатно метрик у нас нет.
На помощь нам приходят
records.На стеке
victoria metrics(да вообще и в прометиусе тоже на самом деле) мы легко можем создавать такую сущность как vmalert и vmrule.ВМалёрт просто берёт правила алёртов и отправляет на ручку алёртменеджера.
У vmrule есть две функции:
- создавать
rule для алёртов- создавать новые
recordsТо есть через
records мы можем создавать свои, абсолютно удобные для нас метрики со своими лейблами. Или обогащать существущие метрики новыми лейблами.
Идея тут какая была:
- делаем матчинг между разными видами метрик(у них не матчатся лейблы)
- делаем ещё раз чтобы потом можно было матчить
- создаем матрицу "тип стораджа = максимальный IOPS для него"
- выводим новую метрику "текущий IOPS"
- выводим новую метрику "коэффициент IOPS" где 0 это 0%, а 1 это 100%.
Новую метрику можно использовать как для графиков в графане, так и для алёртов.
На базе подобного подхода мы НЕ зависим какой у нас тип сторадж класса, какой у нас размер PVC и так далее.
У нас есть матчинг POD-PVC-StorageClass-IOPS и мы просто готовую метрику получаем, а калькуляция уже внутри.
Например
pvc_iops_utilization_percent = 80 говорит о том, что мы для этого кластера/неймспейса/пода упирираемся в 80% от возможностей этого диска, использующего этот тип стораджа класса.И нам не важно какой там сторадж класс. мы просто знаем, что считаеся всё внутри Victoria metrics и мы просто на выходе получаем готовую метрику с лейблами (cluster namespace po etc) и мы дальше это где угодно используем:
- графана дашборды
- алёрты
❕Важно понимать, что это пока мой около MVP, в арифметике или логике могут быть мои ошибки, опечатки, неточности и в будущем я буду планировать это анализировать и актуализировать реальным данным.
Я могу по своему не знанию чего-то не учитывать и обязательно это поправлю в будущем.
#azure #metrics #victoriametrics
👏3👍1
---
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAlert
metadata:
name: ${NAME}
namespace: ${NAMESPACE}
spec:
replicaCount: 1
datasource:
url: ${URL_DATASOURCE}
notifier:
url: ${URL_NOTIFIER}
evaluationInterval: "30s"
selectAllByDefault: true
remoteWrite:
url: http://vminsert-victoria-metrics-cluster.service:8480/insert/0/prometheus/
---
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMRule
metadata:
name: vmrule-storage-iops
namespace: ${NAMESPACE}
spec:
groups:
- name: storage_monitoring
interval: 30s
rules:
- record: storage_class_iops_limits
expr: |
sum by(persistentvolume, storageclass, cluster) (
(kube_persistentvolume_info{storageclass=~"azureblob-fuse-premium|azureblob-nfs-premium"} * 15000) or
(kube_persistentvolume_info{storageclass=~"managed-premium|managed-csi-premium|managed-premium-burstable"} * 20000) or
(kube_persistentvolume_info{storageclass=~"managed|managed-csi|default"} * 6000) or
(kube_persistentvolume_info{storageclass="managed-csi-os-warm-nodes"} * 6000) or
(kube_persistentvolume_info{storageclass=~"azurefile-premium|azurefile-csi-premium|azurefile-nonroot|azurefile-sc-fips|sc-rwm"} * 100000) or
(kube_persistentvolume_info{storageclass=~"azurefile|azurefile-csi|azurefile-standart-nonroot"} * 10000) or
(kube_persistentvolume_info * 500)
)
- record: pod_pvc_info
expr: |
max by(cluster, exported_namespace, pod, persistentvolumeclaim) (
kube_pod_spec_volumes_persistentvolumeclaims_info
)
- record: pvc_storage_info
expr: |
max by(cluster, exported_namespace, persistentvolumeclaim, storageclass) (
kube_persistentvolumeclaim_info
)
- record: pvc_current_iops
expr: |
sum by(cluster, pod, namespace, persistentvolumeclaim, storageclass) (
(
rate(container_fs_reads_total{
device!~"(/dev/)?(mmcblk.p.+|nvme.+|rbd.+|vd.+|xvd.+|dm-.+|md.+|dasd.+)",
device=~"/dev/sd[b-z].*"
}[5m]) +
rate(container_fs_writes_total{
device!~"(/dev/)?(mmcblk.p.+|nvme.+|rbd.+|vd.+|xvd.+|dm-.+|md.+|dasd.+)",
device=~"/dev/sd[b-z].*"
}[5m])
)
)
* on(cluster, pod) group_left(persistentvolumeclaim, exported_namespace)
pod_pvc_info
* on(cluster, exported_namespace, persistentvolumeclaim) group_left(storageclass)
pvc_storage_info
- record: pvc_iops_utilization_percent
expr: |
sum by(cluster, namespace, pod, persistentvolumeclaim, storageclass) (pvc_current_iops)
* 100
/ on(cluster, storageclass) group_left()
max by(cluster, storageclass) (storage_class_iops_limits)
---
- alert: HighIOPSUtilization
expr: round(pvc_iops_utilization_percent) > 85
for: 40m
labels:
severity: warning
annotations:
summary: "IOPS is `{{ $value }}%` on `{{ $labels.cluster }}`/`{{ $labels.namespace }}`/`{{ $labels.pod }}`."
✍1
Ну вот и график в графане.
Максимум IOPS(из документации Ажура) и текущая нагрузка.
#azure #metrics #victoriametrics
Максимум IOPS(из документации Ажура) и текущая нагрузка.
#azure #metrics #victoriametrics
😁2👍1
Утро началось с осознания, что:
- кросс-кластер алертинг нужен иногда (и он сработал)
- частоту верещания этого, пусть и важнейшего алерта, можно уменьшить
- киверно это пздц ублюдочная хйня, уронил весь кластер. Точнее он и Харбор.
Про киверно отдельно напишу всратую стори, это просто глупо как он работает. 🙈
* Кросс-кластер алертинг это когда есть система мониторинга и алертинга и есть где-то далеко в стороне система наблюдающая за ней. И обе друг за другом. Чтобы если вообще всё упало, то было кому сообщать, что всё упало. Про него тоже отдельно напишу пост, как раз материал для шеринга 😅
- кросс-кластер алертинг нужен иногда (и он сработал)
- частоту верещания этого, пусть и важнейшего алерта, можно уменьшить
- киверно это пздц ублюдочная хйня, уронил весь кластер. Точнее он и Харбор.
Про киверно отдельно напишу всратую стори, это просто глупо как он работает. 🙈
* Кросс-кластер алертинг это когда есть система мониторинга и алертинга и есть где-то далеко в стороне система наблюдающая за ней. И обе друг за другом. Чтобы если вообще всё упало, то было кому сообщать, что всё упало. Про него тоже отдельно напишу пост, как раз материал для шеринга 😅
🔥8
#victoriametrics
Итак, кросс-алёртинг.
Название мною выдуманное, я не знаю как такие вещи должны называться, может давно уже другое официальное слово есть.
Допустим у вас есть система мониторинга, трейсинга и алёртинга.
Это может быть
Она работает в кластере или нескольких.
Оповещает по алёртам ваш Slack/PagerDuty/telegram etc.
Всё работает и всё отлично.
А что делать, если POD с Alertmanager упал? Что делать, если у вас накрылся весь кластер?
Вы ведь даже не узнаете об этом - некому сообщить о том, что всё упало.
Есть готовые реализации, но нам не подошло большинство из-за цены, способа интеграции или недостаточного для меня функционала. А что это значит? Прааааавильно, пишем свой велосипед😅.
У
Этот алёрт горит ВСЕГДА.
То есть "если у алёртменеджера всё хорошо" - значит горит алерт.
Если "если вочдог не горит" - алертменеджер умер/конфиг с ошибкой/недоступен и так далее.
Логика наоборот.
В зависимости от вашей системы обсервабилити и способа установки он может быть включен по умолчанию, но если его нет, то вы его легко можете добавить(пример для VM стека):
Итак, алёрт у нас есть.
Дальше что?
А дальше идея такая:
- мы пишем новый микросервис, пусть будет на Python, все переменные в хардкоде для удобства этого демо
https://github.com/kruchkov-alexandr/cross-alerting/blob/main/main.py
- пишем докерфайл для запуска в кубах (я вообще не заморачивался с оптимизацией тут)
https://github.com/kruchkov-alexandr/cross-alerting/blob/main/Dockerfile
- деплоим его в ДРУГОЙ/ДРУГИЕ кластера кубернетиса, можно хоть хелм чарт на него написать, если есть желание, у меня сделано через ArgoCD - путь к имаджу и переменные и всё
- в конфиг алертменеджера добавляем новый route и receiver чтобы watchdog alert отправлялся в новый микросервис
Итак, кросс-алёртинг.
Название мною выдуманное, я не знаю как такие вещи должны называться, может давно уже другое официальное слово есть.
Допустим у вас есть система мониторинга, трейсинга и алёртинга.
Это может быть
kube-prometheus-stack или victoria-metrics-k8s-stack или любой другой стек или оператор.Она работает в кластере или нескольких.
Оповещает по алёртам ваш Slack/PagerDuty/telegram etc.
Всё работает и всё отлично.
А что делать, если POD с Alertmanager упал? Что делать, если у вас накрылся весь кластер?
Вы ведь даже не узнаете об этом - некому сообщить о том, что всё упало.
Есть готовые реализации, но нам не подошло большинство из-за цены, способа интеграции или недостаточного для меня функционала. А что это значит? Прааааавильно, пишем свой велосипед😅.
У
Alertmanager есть механизм, который называется Watchdog.Этот алёрт горит ВСЕГДА.
То есть "если у алёртменеджера всё хорошо" - значит горит алерт.
Если "если вочдог не горит" - алертменеджер умер/конфиг с ошибкой/недоступен и так далее.
Логика наоборот.
В зависимости от вашей системы обсервабилити и способа установки он может быть включен по умолчанию, но если его нет, то вы его легко можете добавить(пример для VM стека):
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMRule
...
spec:
groups:
...
- name: "alertmanager"
rules:
- alert: Watchdog
expr: vector(1)
for: 5m
labels:
severity: info
annotations:
summary: "This is an Watchdog alert that is always firing."
...
Итак, алёрт у нас есть.
Дальше что?
А дальше идея такая:
- мы пишем новый микросервис, пусть будет на Python, все переменные в хардкоде для удобства этого демо
https://github.com/kruchkov-alexandr/cross-alerting/blob/main/main.py
- пишем докерфайл для запуска в кубах (я вообще не заморачивался с оптимизацией тут)
https://github.com/kruchkov-alexandr/cross-alerting/blob/main/Dockerfile
- деплоим его в ДРУГОЙ/ДРУГИЕ кластера кубернетиса, можно хоть хелм чарт на него написать, если есть желание, у меня сделано через ArgoCD - путь к имаджу и переменные и всё
- в конфиг алертменеджера добавляем новый route и receiver чтобы watchdog alert отправлялся в новый микросервис
route:
...
routes:
##############################################################
# Watchdog #
##############################################################
# DO NOT REMOVE THIS ROUTE!!!
# DO NOT ADD ROUTES ABOVE!!!
- receiver: 'webhook-receiver'
group_wait: 10s
group_interval: 30s
repeat_interval: 30s
matchers:
- alertname = "Watchdog"
continue: true
...
receivers:
...
- name: 'webhook-receiver'
webhook_configs:
- url: 'https://cross-alerting.domain.io/api/alert'
send_resolved: true
....
✍3
Собственно и всё:
- алертменеджер каждые 5 минут отправляет вебхуки на URL cross-alerting
- скрипт запускает веб-сервер, который слушает POST-запросы на /api/alert.
- каждый раз, когда приходит запрос на этот endpoint, обновляется время последнего вебхука.
- в фоновом режиме работает тред, который проверяет, как давно приходил последний вебхук.
- если вебхук не приходил дольше, чем WEBHOOK_CHECK_INTERVAL(2 минуты), система считается "упавшей", и отправляется уведомление в Slack.
- если система была "упавшей", но вебхук пришел, отправляется уведомление о восстановлении.
- если pod был перезапущен в течение последних 30 секунд, отправляется уведомление о восстановлении.
* Давайте ток не душнить про овнокод на питоне и докерфайл, задачи по оптимизации не стояло.
Надо было просто написать так, чтобы перекрёстный мониторинг и алёртинг работал, он работает, а значит задача решена. Для себя можете писать Свой Идеальный Божественный Код.
- алертменеджер каждые 5 минут отправляет вебхуки на URL cross-alerting
- скрипт запускает веб-сервер, который слушает POST-запросы на /api/alert.
- каждый раз, когда приходит запрос на этот endpoint, обновляется время последнего вебхука.
- в фоновом режиме работает тред, который проверяет, как давно приходил последний вебхук.
- если вебхук не приходил дольше, чем WEBHOOK_CHECK_INTERVAL(2 минуты), система считается "упавшей", и отправляется уведомление в Slack.
- если система была "упавшей", но вебхук пришел, отправляется уведомление о восстановлении.
- если pod был перезапущен в течение последних 30 секунд, отправляется уведомление о восстановлении.
* Давайте ток не душнить про овнокод на питоне и докерфайл, задачи по оптимизации не стояло.
Надо было просто написать так, чтобы перекрёстный мониторинг и алёртинг работал, он работает, а значит задача решена. Для себя можете писать Свой Идеальный Божественный Код.
👍3
Ночь, бессонница.
Горение.
Читаю комментарии к разным статьям про развитие UI/UX, про размеры приложений на телефон в 1300 мегабайт для чтения pdf файлов без редактирования.
Про максимально ставший абсолютным рекордсменом говна - ноушн. Я словно Нео в драке с мистером Андерсоном отбиваюсь каждый день от новых всплывающих окон с НУ ВОТ ТЕПЕРЬ ТОЧНО НОВАЯ ПОЛЕЗНАЯ ФИЧА ХОТЬ ТЫ И НЕ ПРОСИЛ НА ВОТ СОРТИРУЙ СВОИ СЧЕТА ЗА АПРЕЛЬ ПО НОВОМУ AI В ЗАМЕТКАХ.
Не менее всратый слак - джигурдаллион фичей ежедневно, половина из них умерло до их релиза и, особенно, использования реальными людьми.
Везде AI. Везде pop-up, бесячая джира и конфлюенс каждый день(!) высирает новые окошки с новой абсолютно бесполезной херней.
Мы уже даже привыкли их закрывать, многим реально понасрать что там у вас вышло.
Ноушн, банк клиент, стриминг плеер. Открыл Яндекс музыку - автоматически оформил ипотеку в Перми.
Люди, разработчики, аналитики, корпорации - все они/мы перестали делать ПРОСТО ПРИЛОЖЕНИЕ.
То, ради чего к ним пришли и пользуются/платят.
Не добавляя сторизы в калькулятор, не добавляя предложение о кредите в фотоальбом.
Все наши телефоны от 50 баксов с Али до топов за 3000, умеют на Марс летать и рассчитывать орбиту геостационарных спутников за 0.00001наносекунд, но ослиное приложение по просто вызову такси тормозит так, что я уже пешком дошёл, потому что у нас ЭКОСИСТЕМА СУПЕРАПП. 😂
Я реально прекратил пользоваться около 25 приложениями, потому что вместо простого и обещанного функционала оно превратилось в ишачий кал с AI и сторизами от курьеров-случайных-контактов из Узбекистана.
Кое-кто даже перестал выполнять свою изначальную функцию, что печалит.
Бог с ним, с размером, благо у нас больше не дискетки, что произошло с главным - функционалом?
Что не так с индустрией? Почему мы начали делать говно?
Не соглашусь, что мы всегда делали говно, ещё есть приложения, которые всё ещё просто делают свою работу.
Кто виноват? Зумеры айтишники? AI проклятый век? Эффективные менеджеры?
Старые пердуны сишники?
Вкатуны(как я)? Или всё испортили статьи про аджайл и влажные маня фантазии инвесторов?
Кому разбить лицо?
* Возгорание произошло из-за обновления Spotify, он мне на ПК вертикальные сторизы-тизеры-песен-без-способности-прослушать-весь-трек выдал😂 . На ПК🤭 .
Зачем это дерьмо вообще релизили?
Горение.
Про максимально ставший абсолютным рекордсменом говна - ноушн. Я словно Нео в драке с мистером Андерсоном отбиваюсь каждый день от новых всплывающих окон с НУ ВОТ ТЕПЕРЬ ТОЧНО НОВАЯ ПОЛЕЗНАЯ ФИЧА ХОТЬ ТЫ И НЕ ПРОСИЛ НА ВОТ СОРТИРУЙ СВОИ СЧЕТА ЗА АПРЕЛЬ ПО НОВОМУ AI В ЗАМЕТКАХ.
Не менее всратый слак - джигурдаллион фичей ежедневно, половина из них умерло до их релиза и, особенно, использования реальными людьми.
Везде AI. Везде pop-up, бесячая джира и конфлюенс каждый день(!) высирает новые окошки с новой абсолютно бесполезной херней.
Мы уже даже привыкли их закрывать, многим реально понасрать что там у вас вышло.
Ноушн, банк клиент, стриминг плеер. Открыл Яндекс музыку - автоматически оформил ипотеку в Перми.
Люди, разработчики, аналитики, корпорации - все они/мы перестали делать ПРОСТО ПРИЛОЖЕНИЕ.
То, ради чего к ним пришли и пользуются/платят.
Не добавляя сторизы в калькулятор, не добавляя предложение о кредите в фотоальбом.
Все наши телефоны от 50 баксов с Али до топов за 3000, умеют на Марс летать и рассчитывать орбиту геостационарных спутников за 0.00001наносекунд, но ослиное приложение по просто вызову такси тормозит так, что я уже пешком дошёл, потому что у нас ЭКОСИСТЕМА СУПЕРАПП.
Я реально прекратил пользоваться около 25 приложениями, потому что вместо простого и обещанного функционала оно превратилось в ишачий кал с AI и сторизами от курьеров-случайных-контактов из Узбекистана.
Кое-кто даже перестал выполнять свою изначальную функцию, что печалит.
Бог с ним, с размером, благо у нас больше не дискетки, что произошло с главным - функционалом?
Что не так с индустрией? Почему мы начали делать говно?
Не соглашусь, что мы всегда делали говно, ещё есть приложения, которые всё ещё просто делают свою работу.
Кто виноват? Зумеры айтишники? AI проклятый век? Эффективные менеджеры?
Старые пердуны сишники?
Вкатуны(как я)? Или всё испортили статьи про аджайл и влажные маня фантазии инвесторов?
Кому разбить лицо?
* Возгорание произошло из-за обновления Spotify, он мне на ПК вертикальные сторизы-тизеры-песен-без-способности-прослушать-весь-трек выдал
Зачем это дерьмо вообще релизили?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8💯4🤣3