Для себя Решить задачу: В нашем проекте мы используем виртуальные серверы, каждый из которых имеет два независимых сетевых интерфейса. На каждом интерфейсе присутствуют адреса как IPv4, так и IPv6. Для того, чтобы не запутаться во всех этих адресах, мы используем DNS. Так у каждого сервера появляется два имени: в зоне kit.yandex.net для первого интерфейса в зоне ya.kit.com для второго Все записи выглядят как contest-XXXX.domain., но из-за особенностей работы приложения, числа, замещающие XXXX могут быть разными. Например, один и тот же сервер может иметь такие записи: contest-123.kit.yandex.net 600 IN A 10.1.2.3 contest-123.kit.yandex.net 600 IN AAAA fc01::fe12:5416 contest-1154.ya.kit.com 600 IN A 10.2.7.16 contest-1154.ya.kit.com 600 IN AAAA fc02::de12:3217 Число во втором названии может быть получено из первого названия, если взять первые три символа hex-представления md5 и преобразовать их в десятичное число. Для примера выше: $ echo $((0x$(echo -n contest-123.kit.yandex.net | md5sum | head -c 3))) 1154 Мы обнаружили, что в зоне ya.kit.com отсутствуют некоторые IPv6-записи. Вам необходимо найти все виртуальные машины (их fqdn в зоне kit.yandex.net) у которых отсутствуют записи в ya.kit.com Формат ввода Ваше приложение будет запущено в каталоге, в котором есть два файла: a.input и b.input В них содержатся, соответственно, выгрузки зоны kit.yandex.net и зоны ya.kit.com. Формат вывода В качестве ответа выведите отсортированный (по идентификатору в fqdn) список доменных имён (kit.yandex.net) без IPv6-записей во второй зоне (ya.kit.com) Формат ответа: contest-123.kit.yandex.net contest-124.kit.yandex.net contest-125.kit.yandex.net contest-126.kit.yandex.net 2) задача Ввод стандартный ввод или input.txt Вывод стандартный вывод или output.txt В нашем сервисе есть веб-сервер, который раздает полезные данные пользователям. Мы хотим понимать, из каких стран и городов к нам приходят пользователи, поэтому мы хотим разметить журнал запросов веб-сервера дополнительной информацией. Для решения задачи у вас времени не нашлось, зато время оказалось у стажера, который написал программу, размечающую лог запросов названиями стран из базы. К сожалению, когда вы добрались проверить эту программу, стажер оказался в отпуске. Программа выглядит рабочей, но есть несколько нюансов: она работает не очень быстро; она иногда потребляет много памяти; иногда она работает не совсем корректно; она размечает только страны, но не размечает города. Ниже приложен код программы. Ваша задача: найти и исправить логическую ошибку в коде; ускорить работу программы; уменьшить потребляемую память; добавить в разметке название города сразу после названия страны. Если программа выдает неправильные значения, то оптимизировать ее рано. Пример строк в файле с геобазой: 112.9.96.0 112.9.127.255 Китай Циндао 112.9.128.0 112.9.255.255 Китай Циндао 112.10.0.0 112.10.127.255 Китай [Телефон скрыт] 112.10.143.255 Китай Ханчжоу [Телефон скрыт] 112.10.159.255 Китай Ханчжоу Пример строк журнала сервера: [Телефон скрыт] - - [10/Jan/2025:07:44:17 +0300] “GET /server HTTP/1.1“ 200 7881 “-“ “Go-http-client/1.1“ [Телефон скрыт] - - [10/Jan/2025:07:44:17 +0300] “GET /.vscode/sftp.json HTTP/1.1“ 301 319 “-“ “Go-http-client/1.1“ [Телефон скрыт] - - [10/Jan/2025:07:44:17 +0300] “GET /server HTTP/1.1“ 302 0 “-“ “Go-http-client/1.1“ [Телефон скрыт] - - [10/Jan/2025:07:44:17 +0300] “GET /?rest_route=/wp/v2/users/ HTTP/1.1“ 301 194 “-“ “Go-http-client/1.1“ [Телефон скрыт] - - [10/Jan/2025:07:44:17 +0300] “GET /debug/default/view?panel=config HTTP/1.1“ 301 194 “-“ “Go-http-client/1.1“ Код, который написал стажер: class AddRegionInfo: def __init__(self, geo_file_name, in_log_file_name, out_log_file_name): self.geo_data = self.read_geo_data(geo_file_name) self.process_log(in_log_file_name, out_log_file_name) def read_geo_data(self, file_name): f = open(file_name, 'r') return f.readlines() def process_log(self, in_file_name, out_file_name): f = open(in_file_name, 'r') lines = f.readlines() f = open(out_file_name, 'w') for line in lines: fields = line.split(' ') ip = fields[0] fields[-1] = fields[-1].strip() for geo in self.geo_data: gf = geo.split('\t') if self.is_bigger(ip, gf[0]) and self.is_bigger(ip, gf[1]): fields = [gf[2].strip()] + fields f.write(' '.join(fields) + '\n') break def is_bigger(self, a1, a2): a1s = a1.split('.') a2s = a2.split('.') if a1s[0] > a2s[0]: return True if a1s[1] > a2s[1]: return True if a1s[2] > a2s[2]: return True if a1s[3] > a2s[3]: return True return False if __name__ == '__main__': AddRegionInfo('geobase.txt', 'input.txt', 'output.txt') Примечания Задачу можно делать итеративно Самым важным является правильность значений, нет смысла оптимизировать то, что работает неправильно Поддержку городов можно добавлять в произвольное время, без нее тоже можно получить ненулевой балл за эту задачу 3) задача Василий - новый DevOps в небольшой компании, которая активно использует микросервисы. Продуктовое окружение этой компании использует kubernetes, развёрнутый прямо на “железе“. Недавно произошел инцидент и часть запросов клиентов зависла на каком-то количестве перегруженных машин. Беда в том, что никто не озаботился мониторингом загрузки CPU, и единственный косвенный показатель нагрузки, который у Василия есть - это температура CPU железных серверов. Василий выгрузил в SQLite-базу логи запросов во время инцидента, табличку привязки подов приложений к машинам и лог температурных измерений. Они выглядят следующим образом (тут приведён пример): Табличка requests: | request_id | parent_request_id | pod_id | ts | | ---------- | ----------------- | ------ | ------- | | start1 | NULL | 1 | 10 | | cont1 | start1 | 2 | 12 | | cont2 | cont1 | 2 | 16 | | start2 | NULL | 1 | 29 | Где: request_id - уникальный идентификатор запроса parent_request_id - уникальный идентификатор запроса, породившего данный pod_id - идентификатор пода, на котором был запущен микросервис, принявший запрос ts - unixtime в секундах момента, когда запрос пришел в микросервис У каждого запроса есть id, те запросы, что были порождены не клиентом, а внутренними микросервисами, имеют parent_request_id. При этом граф вызовов между микросервисами может быть произвольно большим. Табличка pods: | pod_id | machine_id | | ------ | ---------- | | 1 | 1 | | 2 | 2 | Где: pod_id - идентификатор пода machine_id - идентификатор железной машины, на которой он запущен (на одной машине может быть запущено много подов, десятки/сотни) Табличка measurements: | machine_id | ts | temperature | | ---------- | -- | ----------- | | 1 | 10 | 62 | | 1 | 17 | 61 | | 1 | 23 | 63 | | 1 | 31 | 61 | | 2 | 9 | 70 | | 2 | 15 | 86 | | 2 | 21 | 92 | | 2 | 30 | 89 | Где: machine_id - идентификатор железной машины ts - unixtime момента, когда было снято измерение (на каждой машине измерения снимаются не чаще 1 раза в 5 секунд и не реже 1 раза в 10 секунд) temperature - температура CPU в градусах Цельсия Василий почитал документацию к используемым в компании процессорам и определил, что признаком перегруженного CPU будет его температура выше 85 градусов. Помогите Василию оценить, сколько запросов клиентов пострадало. Для этого составьте SQL-запрос, который выведет список request_id клиентов, графы вызовов которых оборвались на перегруженных машинах. Например, для приведенных выше примеров таблиц, таким запросом будет запрос с request_id start1. Задача является достаточно сложной, имеет смысл начать с отладки локально: Скачайте бинарную сборку SQLite (https://www.sqlite.org/download.html) или поставьте его любым удобным вам способом, например, с помощью пакетного менеджера вашего дистрибутива Linux. Создайте БД и заполните таблицы, как показано в примере выше. Попробуйте написать SQL-запрос, который найдет запрос с request_id cont2. Попробуйте написать SQL-запрос, который сможет найти start1 по цепочке вверх или вниз (как вам удобно). Если у вас не получается пункт 4 - сдавайте запрос из пункта 3