Заодно мы развернем приложение в Serverless Containers - сервисе Яндекс.Облака, который запускает Docker-контейнер только в тот момент, когда происходит обращение к нему. И уместимся в Serverless Free Tier, чтобы приложение работало почти бесплатно.

Запуск контейнера

Для того, чтобы приложение корректно запустилось в Serverless Containers, нужно добавить переменную окружения PORT, которая будет устанавливать порт для запуска приложения. Итоговый Dockerfile для Django может выглядеть вот так:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

FROM python:3.10

ENV PYTHONUNBUFFERED 1

WORKDIR /app

COPY requirements.txt .

RUN pip install -r requirements.txt

# указываем переменную окружения
ENV PORT 8000

COPY . .

RUN python manage.py collectstatic --no-input

# gunicorn должен быть указан в requirements.txt
# projectname нужно заменить на пакет с Django-проектом
CMD gunicorn --chdir src --bind 0.0.0.0:$PORT projectname.wsgi

Далее собираем контейнер:

• docker build -t myproject . - собираем образ
• docker run -ti --rm -p 8000:8000 myproject - запускаем контейнер
• открываем в браузере http://localhost:8000 и проверяем, кто приложение работает правильно.

Далее по инструкции Яндекс.Облака запускаем контейнер.

Подключение к очереди сообщений

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

Celery поддерживает несколько брокеров сообщений, но нас интересует Amazon SQS в первую очередь, так как Yandex Message Queue имеет поддержку Amazon SQS API.

Первым делом создаем Message Queue по официальной инструкции.

По умолчанию Celery настроен на работу с Amazon SQS. Чтобы настроить Celery для работы с Yandex Message Queue, немного поменяем settings.py:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# по умолчанию указан Redis, но позже мы установим подключение к Yandex Message Queue
CELERY_BROKER_URL = os.environ.get("CELERY_BROKER_URL", "redis://localhost:6379/0")

# указываем дополнительные опции для передачи сообщений, если устанавливается подключение к SQS
SQS_QUEUE = os.environ.get("SQS_QUEUE")
if SQS_QUEUE:
    CELERY_BROKER_TRANSPORT_OPTIONS = {
        'is_secure': True,
        'predefined_queues': {
            'default': {
                'url': SQS_QUEUE,
                'access_key_id': os.environ.get("SQS_ACCESS_KEY_ID"),
                'secret_access_key': os.environ.get("SQS_SECRET_ACCESS_KEY"),
            }
        },
        'region': os.environ.get("SQS_REGION")
    }

Указываем переменные окружения c заменой {ПЕРЕМЕННЫХ} на значения, полученные при создании очереди:

1
2
3
4

CELERY_BROKER_URL=sqs://{ACCESS_KEY}:{SECRET_KEY}@message-queue.api.cloud.yandex.net
SQS_ACCESS_KEY_ID={ACCESS_KEY}
SQS_SECRET_ACCESS_KEY={SECRET_KEY}
SQS_REGION={REGION}  # например, ru-central1

Для указания переменных окружения можно использовать модуль dotenv и файл .env . Если вы тестируете работу сразу в Яндекс.Облаке, то переменные окружения можно указать при создании новой версии контейнера.

Устанавливаем дополнение Celery для работы с SQS:

• pip: pip install celery[sqs]
• poetry: poetry add 'celery[sqs]'

После этого запускаем проект и пробуем добавить задачу в очередь (например, вызываем какой-нибудь URL, в котором происходит task.delay()).

Запуск воркеров через POST-запрос

Организовать обработку сообщений, поступающих в очередь, можно несколькими способами

1. запустить celery worker, который будет сам забирать сообщения и обрабатывать их
2. настроить триггер в Yandex Message Queue, который будет вызывать Cloud Function или делать HTTP-запрос куда-либо при появлении нового сообщения.

Мы воспользуемся вторым способом и настроим HTTP-вызов при появлении сообщения в очередь. Чтобы этот вызов обрабатывался, добавим новый view в Django.

TLDR: ниже есть код готового обработчика запросов для Django

Тело HTTP-запроса с сообщением от Celery выглядит примерно так (некоторые данные скрыты):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

{
    "messages":
    [
        {
            "event_metadata":
            {
                "event_id": "...",
                "event_type": "yandex.cloud.events.messagequeue.QueueMessage",
                "created_at": "2022-09-02T05:38:46.026Z",
                "tracing_context": null,
                "cloud_id": "...",
                "folder_id": "..."
            },
            "details":
            {
                "queue_id": "...",
                "message":
                {
                    "message_id": "...",
                    "md5_of_body": "...",
                    "body": "BODY",
                    "attributes":
                    {
                        "ApproximateFirstReceiveTimestamp": "1662097126149",
                        "ApproximateReceiveCount": "1",
                        "SentTimestamp": "1662097126026"
                    },
                    "message_attributes":
                    {},
                    "md5_of_message_attributes": ""
                }
            }
        }
    ]
}

В этом сообщении нас интересует BODY - в нем содержится json, который отправил Celery, закодированный в base64. Если его раскодировать, мы увидим примерно следующее:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

{
    "body": "BODY2",
    "content-encoding": "utf-8",
    "content-type": "application/json",
    "headers":
    {
        "lang": "py",
        "task": "TASK",
        "id": "...",
        "shadow": null,
        "eta": null,
        "expires": null,
        "group": null,
        "group_index": null,
        "retries": 0,
        "timelimit":
        [
            null,
            null
        ],
        "root_id": "...",
        "parent_id": null,
        "argsrepr": "...",
        "kwargsrepr": "{}",
        "origin": "gen83@yc-serverless",
        "ignore_result": false,
        "headers": {}
    },
    "properties":
    {
        "correlation_id": "...",
        "reply_to": "...",
        "delivery_mode": 2,
        "delivery_info":
        {
            "exchange": "",
            "routing_key": "default"
        },
        "priority": 0,
        "body_encoding": "base64",
        "delivery_tag": "..."
    }
}

Вместо TASK выше будет что-то типа appname.tasks.function_name (т. е. путь до функции-обработчика задачи). BODY2 - это опять json в base64 с аргументами команды:

1
2
3
4
5

[
    ["value1", "value2"], 
    {}, 
    {"callbacks": null, "errbacks": null, "chain": null, "chord": null}
]

В нем - tuple с тремя аргументами: args, kwargs, options. Эта информация должна быть передана в таск для того, чтобы вызвать его с правильными параметрами.

В итоге код обработчика запросов выглядит так:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

@api_view(["POST"])  # декоратор из django rest framework
def worker_view(request):
    # request.data - JSON из тела запроса
    for message in request.data['messages']:
        # декодируем сообщение
        data_json = base64.b64decode(message['details']['message']['body']).decode()
        data = app.backend.decode(data_json)

        # находим функцию с таском
        module_path = data['headers']['task'].split('.')
        package_path = ".".join(module_path[:-1])
        function_name = module_path[-1]
        module = importlib.import_module(package_path)
        function = getattr(module, function_name)

        # делаем принудительное сохранение результатов (об этом ниже)
        store_result_original_value = app.conf.task_store_eager_result
        app.conf.task_store_eager_result = True

        # достаем аргументы
        args, kwargs, options = json.loads(base64.b64decode(data['body']))

        # вызываем таск
        result = function.apply(
            args=args, 
            kwargs=kwargs, 
            task_id=data['headers']['id'], 
            headers=data['headers']['headers'], 
            **options
        )

        # возвращаем настройки в исходное положение
        app.conf.task_store_eager_result = store_result_original_value

        # возвращаем ответ в зависимости  от успешности обработки задачи
        if not result.successful():
            capture_exception(result.info)
            return JsonResponse({"status": "error", "info": str(result.info)})

    return JsonResponse({"status": "ok"}, status=200)

Такая обработка задач поддерживает не все возможности Celery, но позволяет запустить простейшую обработку в Serverless Containers

Подключаем его в urls.py:

1

path("worker/", worker, name='worker')

Создание триггера

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

Подскажу некоторые параметры, которые нужно указывать при создании триггера, на примере команды для консоли:

1
2
3
4
5
6
7

yc serverless trigger create message-queue \
      --name=NAME \
      --queue QUEUE \
      --queue-service-account-id SERVICE_ACCOUNT_ID \
      --invoke-container-service-account-id SERVICE_ACCOUNT_ID \
      --invoke-container-id CONTAINER_ID \
      --invoke-container-path CONTAINER_PATH

замените параметры:

• NAME - название триггера
• QUEUE - arn очереди (строка вида yrn:yc:ymq:REGION:FOLDER_ID:QUEUE_NAME, можно скопировать на странице очереди в консоли Яндекс.Облака)
• SERVICE_ACCOUNT_ID - ID сервисного аккаунта
• CONTAINER_ID - ID контейнера
• CONTAINER_PATH - URL-адрес в контейнере, который занимается обработкой сообщений из очереди (в нашем случае - это /worker/)

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

Сохранение результатов обработки задач

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

Механизм сохранения работает на базе celery result backends. Нас сейчас интересует AWS DynamoDB backend, так как в Яндексе есть Yandex Database Serverless, поддерживающая DynamoDB API.

Создаем Yandex DB Serverless по официальной инструкции. Serverless-режим тарифицируется по использованию и бесплатные квоты.

Устанавливаем дополнение Celery для работы с DynamoDB:

• pip: pip install celery[sqs,dynamodb]
• poetry: poetry add 'celery[sqs,dynamodb]'

Добавляем новую константу в settings.py:

1

CELERY_DYNAMODB_ENDPOINT_URL = os.environ.get("CELERY_DYNAMODB_ENDPOINT_URL")

Устанавливаем значение этой переменной из параметра Document API Endpoint (доступен на странице Yandex DB в консоли Яндекс.Облака).

Поясню про принудительное сохранение результатов в коде обработчика задачи. Дело в том, что принудительный вызов Celery-задач с помощью apply() возвращает EagerResult, который по умолчанию не должен сохраняться. В нашей ситуации, наоборот, нужно сохранять такие результаты, поэтому мы сначала устанавливаем настройку в нужное нам положение, а потом возвращаем все как было, чтобы не мешать другим процессам, происходящим в приложении.

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

Настройка домена

В Яндекс.Облаке есть API Gateway для соединения нескольких сервисов под один хост. У нас по факту лишь один сервис, который предназначен для общения с внешним миром (это наш serverless container, развернутый в самом начале).

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

Создадим API Gateway по официальной инструкции, но в конфигурации укажем примерно следующее:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

openapi: "3.0.0"
info:
  version: 1.0.0
  title: PROJECT NAME
paths:
  /{url+}:
    x-yc-apigateway-any-method:
      summary: Execute container
      operationId: container
      parameters:
      - explode: false
        in: path
        name: url
        required: false
        style: simple
      x-yc-apigateway-integration:
        type: serverless_containers
        container_id: CONTAINER_ID
        service_account_id: SERVICE_ACCOUNT_ID

Здесь указано, что все запросы, приходящие на API Gateway, будут переадресовываться на serverless container. Нужно заменить некоторые параметры:

• PROJECT NAME - название проекта
• CONTAINER_ID - ID контейнера
• SERVICE_ACCOUNT_ID - ID сервисного аккаунта

После создания появится адрес API Gateway, по которому можно будет обращаться к нашему приложению извне.

Теперь можно подключить свой домен и настроить HTTPS сертификат с помощью Let’s Encrypt прямо в консоли Яндекс.Облака.

Free Tier

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

Действительно, Serverless Containers, Message Queue, YDB Serverless, API Gateway имеют определенный объем услуг, который не тарифицируется.

Yandex Database может работать на выделенных серверах, и тарифицироваться это будет значительно дороже. Мы использовали Serverless-вариант, входящий в Free Tier.

Используемый нами Yandex Container Registry тарифицируется. На момент написания статьи 3 руб/месяц за 1ГБ хранения. Чтобы сэкономить и здесь, можно настроить автоудаление образов, так как после деплоя контейнера они больше будут не нужны.

В статье не рассматривалось подключение к PostgreSQL/MySQL. Можете ознакомиться с их стоимостью на сайте Яндекс.Облака и принять решение об использовании их в своем проекте.

Автоматизация

Автоматизировать этот процесс можно, например, с помощью Terraform. У Яндекс.Облака есть провайдер, позволяющий настроить большинство сервисов.

На момент написания статьи не было возможности заставить Message Queue trigger запускать serverless container, поэтому мне пришлось вызывать консольную команду через yc для этого.

Посмотреть конфигурационный файл Terraform

Ниже описанные техники были испытаны на себе, пережиты и выведены на основе собственного опыта. Недавно многие из них подкрепились книгой “Джедайские техники” Максима Дорофеева (по ссылке есть интересная инфографика с общей схемой управления потоками дел).

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

Максим Дорофеев несколько раз повторяет: не все практики и техники подойдут каждому. Поэтому в моем списке ниже отдельно будет выделено то, что, на мой взгляд, помогает только мне (но вдруг это и вам тоже поможет). Остальное скорее всего подойдет каждому читателю.

Техники управления делами

• Нужно все выгружать из головы: задачи, заметки, события. Мозг все равно забудет, а устройство/бумага - нет.
• Нужен план на день. Так можно будет быстрее переходить к выполнению других задач, не думая о том, что бы мне поделать сейчас.
• Наш мозг очень ленивый и не любит много думать: каждую задачу надо расписывать максимально просто и подробно. Плохо: “взять справку” (Какую справку? Где?), “купить” (чтобы потом в магазине думать: “а что же надо было купить-то?”). Хорошо: “купить хлеб и молоко” или “взять справку в отделе кадров на 3 этаже”.
• Если времени мало, можно пересмотреть в список задач и сделать какое-то маленькое дело или кусочек от большого.
• В свободные минуты можно пересматривать список задач и упрощать/улучшать/расписывать их подробнее, чтобы ленивому мозгу было проще работать в дальнейшем.
• Для сохранения порядка нужны ежедневные обзоры списка задач: выкидываем неактуальное, обновляем актуальное, переносим то, что точно не успеем (беспорядок демотивирует).
• Переносить задачи на следующий день - не плохо, если есть причины. Во время переноса нужно помнить не только про срок желаемого выполнения, но и про крайний срок (например, хотел сделать домашку в понедельник, но сдавать ее в пятницу. Значит задача может быть перенесена максимум до четверга.)
• Нужны перерывы в работе: организм устает делать одно и то же долгое время, и ему нужен отдых, особенно мозгу и глазам. Про остальные части тела тоже забывать не стоит. Делать регулярные перерывы в работе поможет техника помодоро.
• В состоянии сильного увлечения выполнением какой-либо задачи тратится много сил на что-то одно, а затем не хватает мотивации доделать остальное. Помидорки спасут и тут.
• Нужно выключать уведомления во время работы. Люди могут подождать 25 минут (во время рабочего периода в помидорке), ничего страшного не случится. Если что-то срочное - можно позвонить.
• Нужно устраивать выходные дни или часы и стараться не думать о работе в это время. Постоянная работа без отдыха ведет к выгоранию: апатия, постоянная усталость и нежелание что-либо делать. Не надо так.
• Нужно следить за организмом и подстраивать выполнение задач под свой режим: в моменты повышенной продуктивности (утром) нужно делать более неприятные и/или тяжелые задачи; в моменты пониженной продуктивности (ночь) - то, что попроще и поприятнее.
• Нужно следить за инбоксами организованно: не стоит отвлекаться на мессенжеры и проверку почты во время работы. Лучше выделить отдельный интервал для этого и переносить все, что попросили сделать, в список задач.
• Нормальный сон - это важно, очень важно, прям очень!!! Иначе будут проблемы со здоровьем.
• Абсолютно всё сделать невозможно, нужно уметь отказывать и отказываться.

Мое субъективное

• Нужен общий список для задач со всех контекстов: работа/учеба/хобби/личное. Так проще планировать общую загруженность по всем фронтам.
• Задачи из рабочего трекера задач можно переносить не полностью, а, например, по названию проектов или по паре слов от полной формулировки (есть люди, которым полезно в личном трекере расписать задачу более подробно). В моем случае главное, чтобы была пометка, что надо поработать над этим проектом в этот день.
• Мне проще вести дела в электронном виде: не мнущийся телефон всегда с собой и не требует ручки для внесения изменений.
• Когда работаю не по помидоркам, к вечеру болит голова. Когда не выспался - тоже. Помидорки - тема!

Спасибо Анне Новиковой за помощь в написании статьи.

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

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

Управление продуктом и Agile

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

STATIK

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

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

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

Парное программирование в Dodo Pizza

Антон Бевзюк поделился опытом парного программирования.

В их компании в некоторых отделах у каждого сотрудника на рабочем месте к одному комьютеру подключено по два монитора, мышки и клавиатуры. Это позволяет проводить сессии парного программирования удобным для тела образом. Работа в паре должна вестись с перерывами на 10-15 минут каждый час и не должна превышать 5-6 часов в день, иначе будет накапливаться сильная усталость.

Чтобы навигатор (тот, кто советует) не терял фокус на работе, а драйвер (тот, кто пишет код) не уставал, кроме перерывов, можно применять разные практики парного программирования:

• При TDD разработке можно чередовать роли при переходе к каждому следующему тесту.
• Для избежания споров драйвер может стать “голосовым вводом” в течение небольшого промежутка времени. (“Друг, просто доверься мне, давай сделаем таким образом, а потом посмотрим, что сделаем с этим кодом”)

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

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

Вот фото с реального рабочего процесса при таком подходе (обратите внимание на эмоции):

Я хочу ехать, а не шашечки

Дмитрий Абрамов рассказал, как с помощью нескольких простых правил значительно улучшить работу команды по Agile:

• Ставьте лимиты на количество задач в определенном статусе - человек не может делать несколько дел одновременно.
• Огромный беклог не нужен: все знают, какие 10 задач самые важные, но никто не знает, что важнее для проекта - 56ая задача в беклоге или 58ая.
• Сам беклог нужно разделить на 3 части (новые задачи, баги и костыли), а затем определить, какой процент времени команда будет тратить на каждую из частей этого беклога.
• Для понимания бизнеса создаем отдельную доску в лоб: Todo, In progress, Done, и неважно, что в разработке In progress делится еще на кучу статусов.

О росте компании

Ренат Габдуллин поделился опытом сохранения качества при росте компании. Кратко:

• Фиксируем принципы работы компании - куда и зачем мы все движемся.
• “Хочешь похоронить вопрос - задай его в чат”. Поэтому если вопрос порождает обсуждение - нужно менять канал взаимодействия.
• Фиксируем правила работы сотрудников - чем больше компания, тем меньше возможностей поговорить с каждым, установить дружеские отношения и объяснить, почему все так устроено и как нужно делать. Надо научиться быстрее нанимать людей, вводить их в курс дела и быстрее делать кадровые перестановки.
• Находим мотиваторов на уровне линейных руководителей, а не только в высшем руководстве.
• Развиваем сотрудников.
• Фильтруем проекты.

Разработка

Видеозвонки в Одноклассниках

Александр Тоболь рассказал о том, как они разрабатывали систему видеозвонков.

Оказалось, что

• Whatsapp (и еще некоторые приложения) поддерживает только 4 человека в видеоконференции, потому что данные передаются peer to peer, и при увеличении количества участников все упирается в ширину канала.
• Hangouts тратит больше зарядки и трафика, чем конкуренты, потому что в целях оптимизации серверной инфраструктуры и скорости видео с камеры рендерится в двух качествах (HD и похуже) сразу же на устройстве пользователя.

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

О жизни Frontend-разработчика

Душевный рассказ о тернистом жизненном пути Михаила Синякова снова подтвердил мои мысли о том, что в любой момент времени нужно стремиться к бОльшему, менять мир вокруг себя и развиваться, как бы тяжело не было в конкретный момент времени - Михаил прошел путь от студента неИТ факультета УЛГУ, работы охранником за 10к, веб-мастером за 7к до frontend тимлида в Ростелекоме.

В конце было немного о том, что разделение на junior/middle/senior скорее не про уровень знаний, а про способность взять на себя ответственность.

Кстати, это единственный доклад с секции “Карьера и кадры”, который я посетил. Однако он имеет отношение к разработке, поэтому пусть будет в этой часте статьи :)

PostgreSQL 12 и неизвестные БД

Олег Бартунов рассказал, что в PostgreSQL 12 все, как обычно, быстрее выше сильнее круче быстрее и так далее. А еще поиск по JSONB полям будет еще быстрее. В общем, надо обновляться.

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

Как делается оптимизация?

Андрей Аксенов из Avito показал, как быстро обработать большой CSV-файл на C++. Или на Go. Или на Python. Да даже на PHP все работает почти так же. В общем, выбор технологий не так важен, важны алгоритмы и понимание работы компьютера. Хотел вставить сюда скрин страшного C++ кода, но поберегу ваше зрение и мозг, потому что качество фотографии отвратительное.

Аварии помогают учиться

Алексей Кирпичников из Контура объяснил, как (сразу после инцидента по шаблону с прикреплением временных меток, скриншотов из чата, мониторинга…) и зачем (для обсуждения с командой и решения проблем в рамках одной команды и всей компании) писать постмортемы - отчеты о произошедших в ИТ инфраструктуре инцидентах.

Топ ошибок при работе с PostgreSQL

Алексей Лесовский попросил быть аккуратнее с ORM, транзакциями; использовать SSD для серверов БД; поправлять конфиги, адаптируя их к железу (а не оставлять дефолты); мониторить нагрузку; не бояться репликации и партиционирования; не использовать Postgres для всего подряд (логи должны быть не в основной БД).

От отдела эксплуатации до SRE

Олег Блохин рассказал о том, как ИТ инфраструктура Dodo Pizza выросла с двух человек и 1 сервера до кучи ресурсов в Azure и как они это все поддерживают.

В компании создается новая команда SRE, которые по сути является командой разработчиков с хорошими знаниями в системном администрировании и способностями поддерживать проекты на этапе эксплуатации. В ответственность этой команды входят: availability, latency, performance, efficiency, change management, monitoring, emergency response, capacity planning.

Команду решили назвать именно SRE, а не DevOps, потому что у термина SRE есть сложившееся понимание (благодаря книгам от Google), в то время как DevOps понимается всеми по-разному, а люди, которые откликаются на такие вакансии, обычно слабо понимают и в инфраструктуре, и в коде.

Также Олег подкрепил мои мысли о том, что книга “Философия DevOps” (в оригинале “Effective DevOps”) не несет в себе достаточно качественной информации. Там в осномнов про “давайте жить дружно”, и лишь один полстранички (из 400) про алерты.

И совет прочесть хорошие книжки в конце:

Синхронизируем кучу данных между сервисами

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

Как упростить разработку и поддержку приложений?

Абстракции! Артем Кудряшов продемонстрировал подход по выделению общей абстракции для микросервисного общения.

О конференции

Конференция традиционно проходит в Ленинском мемориале - музей с лекционными и кинозалами, построенный в память В. И. Ленина. “Советский ИТ антужар повсюду”, как говорится.

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

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

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

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

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

А вообще доклады на #стачка2019 очень даже хорошие. Иногда даже глаза разбегаются)

— atnartur (@atnartur) April 27, 2019

Спасибо Stride за билеты!

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

P. P. S. 24 мая 2019 вставлены скриншоты со слайдов вместо фотографий с экрана.

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

Git

Жизнь разработчика очень трудно представить без работы систем контроля версий. В 2013 году у меня вышла пара статей о том, как работать с git: об основах и регистрации на Bitbucket и установке git на Windows. Часть информации в этих статьях устарела, часть остается актуальной по сей день.

В ноябре 2016 я сделал презентацию по основам git, которая включает в себя все объяснение основных команд git, базовое введение в работу с консолью и работу с ветками. Посмотреть ее можно здесь.

Также повторю ссылку на доклад Сергея Сергеева из Яндекса, который я цитировал в 2013 году. Там очень понятно и с примерами объясняются основные принципы работы систем контроля версий.

Docker

В последнее время в своих проектах я использую Docker для запуска и деплоя серверных приложений.

Не так давно у меня вышла статья о принципах контейнерного подхода.

Документация по запаковыванию приложений в Docker содержит еще и инструкцию по запуску деплоя контейнеров через Gitlab CI. Также есть дополненная видеоинструкция по этому поводу, репозиторий и презентация к ней.

Для того, чтобы запускать Gitlab CI раннеры, я собрал специальный образ. Также в репозиторием с исходниками этого образа есть установочные скрипты для docker и docker-compose для систем на базе Debian.

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

Не могу сказать, что ожидания от Стачки 2017 оправдались полностью, но и говорить, что все было ужасно, не буду, так как это мое первое посещение крупной конференции. Однако, лабиринты Ленинского Мемориала и хаотичное расположение локаций, где проходят доклады, “оценить” получилось. Если еще добавить тот факт, что доклады идут друг за другом без перерыва (особенно если модератор не следит за регламентом), то переходы между лекционными залами становятся просто адом.

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

Очень хотелось узнать подробнее про машинное обучение, и во второй день “Стачки” это все же удалось сделать на докладе Никиты Жильцова, который рассказал именно про принципы работы нейронных сетей, а не сделал очередной обзор этой области. Стоит отметить, что Никита является выпускником КФУ и основателем Textocat, а я принимал участие в хакатоне Textocat в 2014 и сейчас учусь в КФУ. Приятно видеть знакомые лица!

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

Во время доклада Ивана Михеева про сложные интеграционные проекты в голове была только одна фраза: “Блин, это же про нас!” Здесь я убедился в том, что правильная, четкая спецификация и грамотное проектирование системы - самое главное.

Огромное спасибо компании Сергею Крылову и всем ребятам за возможность побывать на Стачке! Несмотря на все недочеты, впечатление от конференции осталось положительным:)

Сразу к делу. И так, чтобы подписаться на обновления данных в Google Таблице, нужно:

1. Авторизоваться в Google аккаунте
2. Открыть нужную Google Таблицу
3. В верхнем меню нажать на “Инструменты”, затем “Уведомления”
4. Выбрать параметры получения уведомлений
5. Нажать на кнопку “ОК”.

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

Поиск проблемы осложняется тем, что линукс постоянно заявляет, что no space left on device. Но по факту место на самом деле есть (в нашем случае около 5 гигов), но места все равно нет. Значит надо смотреть айноды.

df -h - посмотреть информацию о занятом пространстве на жестком диске
df -i - посмотреть информацию об айнодах

Первоначально я пытался просто удалять некоторые папки, которые содержат очень много файлов. Я считал, что здесь нет никакой проблемы, просто файлов с логами стало слишком много, и их надо немного почистить. Однако освобожденные 55000 айнод забились через 3 дня.

Вечер понедельника

Утро четверга

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

Чтобы построить дерево всех каталогов и файлов, выполняем команду:

1

tree / > dirs.txt

Команду нужно выполнить с root-правами для того, чтобы в выдачу попали все каталоги системы. Если утилита tree не установлена, устаналиваем ее из репозиторией, например так: apt-get install tree.

В нашем случае сгенерировался файл на 73МБ. После его анализа была найдена папка, в которой скопилось очень много файлов. Для упрощения поиска полного пути до папки, выполняем команду

1

du -h / > dirs.txt

Она покажет нам вес каждой папки и полный путь до нее. Опять же, команда должна выполняться с root-правами.

После того, как был найден полный путь до папки, выяснилось, что в ней содержатся 1098902 файлов на 231 МБ. В получении этих данных помогли команды:

du -h . - подсчет размера текущей папки
ls -f . | wc -l - подсчет количества файлов в текущей папке

Теперь начинаем удалять файлы с помощью

1

rm /path/to/dir -rf

где /path/to/dir - путь до проблемной папки.

После этих операций количество свободных айнод перевалило за миллион. Победа!

Спасибо Андрею Романову за помощь в решении проблем!

Предыстория

Летом мы в команде начали разрабатывать проект на Phalcon 2. В этом проекте установка даты рождения пользователя реализована следующим образом: в браузере работает плагин календаря, который в результате вписывал в поле ввода дату в формате ДД.ММ.ГГГГ.

После отправки формы контроллер отправляет дату в вышеуказанном формате в специальный метод в модели, который превращает строковую дату в timestamp.

1
2
3
4
5
6
7
8
9
10

/* ClientsController */
$info = new Clients();
$info->setBirthday($this->request->getPost("birthday"));
/* Clients model */
class Clients{
    public function setBirthday($birthday){
        $res = strtotime($birthday);
        $this->birthday = $res;
    }
}

Работает этот код хорошо на следующей конфигурации на PHP5.4 и Phalcon 2.0.3. Однако на PHP5.6 и Phalcon 2.0.13 начинаются проблемы. В результате выполнения функции setBirthday(), в поле birthday записывалось значение false.

В первый раз это произошло у моего коллеги на Fedora с PHP5.6 и Phalcon 2.0.13. Я пытался помочь ему разобраться, но, честно сказать, списывал это на локальные баги окружения, потому что у меня все работало хорошо (Windows 10, OpenServer5.2.2, PHP5.6 и Phalcon 2.0.3). На production сервере все тоже работало хорошо (Phalcon 2.0.3).

Интересная особенность, правда? На 2.0.3 работает нормально, а на 2.0.13 нет. Но об этом далее.

Выявление проблемы

Когда проблема проявилась у меня на машине (PHP5.6, Phalcon 2.0.13) я все-таки решил разобраться в ней. И вот что получилось.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class Clients{
    public function setBirthday($birthday){
        var_dump('---');
        var_dump('before strtotime');
        var_dump($birthday); 
        var_dump($this->birthday); 
        $res = strtotime($birthday);
        var_dump($res);
        $this->birthday = $res;
        var_dump('after strtotime');
        var_dump($this->birthday);
        var_dump('///');
    }
}

Расставил отладочные выводы на каждый чих и посмотрел, что происходит в процессе выполнения функции:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// Начинается выполнение ClientsController->editAction(). 
// Доходит до выполнения $info->setBirthday(). 
string(18) "before bithday set" 
string(3) "—" // начало выполнения функции
string(16) "before strtotime" // вывод перед вызовом функции приведения строки к числу
string(10) "09.09.2016" // вывод из аргумента функции setBirthday
string(0) "" // вывод текущего знаения дня рождения ($this->birthday) 
int(1473368400) // результат работы функции приведения строки к числу
string(3) "—" СНОВА начало выполнения функции
string(16) "before strtotime" опять все то же самое
int(1473368400) // приняли уже значение числовое, которое до этого получилось
string(0) "" дата по прежнему пустая 
bool(false) // результат работы функции есесьно false,
// потому что число к числу привести не возможно
string(15) "after strtotime"
bool(false) //после выполнения всего такой результат
string(3) "///" // завершилась первая
string(15) "after strtotime" // 
bool(false) 
string(3) "///" // завершилась вторая

Таким образом, видно, что идет вложенный вызов функции. Контроллер вызывает setBirthday(), она начинает выполняться, потом доходит до установки значения в свойство $this->birthday = $res; и функция начинает выполняться заново, принимает уже числовое значение из strtotime, а потом не может это числовое значение опять привести к числу, потому что strtotime требует строку. Очевидно, что идет какая-то магия, вызов магического метода setBirthday().

Документация Phalcon

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

Не так давно в версии 2.0.11 был закрыт issue, который решает проблему с getters & setters. Таким образом, с версии 2.0.11 они начинают нормально работать, и поэтому на версии 2.0.13 проявлялся баг.

Ну а решение есть в документации: свойства, которые мы меняем через getters/setters должны быть protected.

Я пробовал копать в сторону проводника Windows, Панели управления… Безуспешно. Пробовал Q-Dir и Total Commander и опять не нашел там решения указанной проблемы (возможно, плохо искал).

Решение нашлось в программе Free Commander. Для того, чтобы сортировка папок наравне с файлами включилась, нужно зайти в меню View/Sort by и нажать на пункт “Unsorted”. После этого сортировка выключается, и файлы с папками отбражаются в нужном нам порядке.