Мне тут стало интересно, а на сколько лет можно прожить больше если исключить те факторы риска, на которые можно влиять самому? Чтобы ответить на этот вопрос я взял открытые данные одного из самых масштабных исследований влияния факторов риска на смертность “Global Burden of Disease 2019” [1] и с их помощью рассчитал оценку увеличения ожидаемой продолжительности жизни при условии исключения управляемых факторов риска. Чтобы было интереснее я оформил результаты в виде дашборда куда можно зайти выбрать страну, пол, возраст и факторы риска и посмотреть результаты. Под катом подробнее о процессе обработки данных, исходники самого дашборда на питоне и конечно подробно посмотрим на графики, там интересно.

Содержание:

• Факторы риска и формат работы

• Разглядывание графиков с результатами расчетов

• Популяризация популяционной статистики

• Валидация результатов и встреча с хаосом

• Задача на размышление

• Ссылки и источники

Факторы риска и формат работы

Итак, факторы были взяты следующие:

• Табак (курение, пассивное курение, жевательный табак)

• Употребление алкоголя

• Употребление наркотиков

• Низкая физическая активность

• Небезопасный секс

• Диетические риски (включает 15 различных факторов риска)

• Высокое систолическое артериальное давление

• Высокий индекс массы тела

• Высокий уровень холестерина ЛПНП

• Высокий уровень глюкозы в плазме натощак

Результаты с рассчитанной оценкой увеличения ожидаемой продолжительности жизни при исключении приведенных выше факторов я оформил в виде интерактивного дашборда и выложил в открытый доступ https://life-extension-3oyids3kha-uc.a.run.app

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

Так же, в открытом доступе на github исходный код и код обработки данных [2, 3]. Реализовано все на питоне, с помощью библиотек Plotly и Dash, для создания интерактивных дашбордов на мой взгляд очень простое и гибкое решение. Все добро упаковывается в докер контейнер и разворачивается с помощью Google Cloud Run – это так называемый serverless хостинг, позволяет экономить за счет того, что использует вычислительные ресурсы только когда кто-то заходит по ссылке, идеальное решение для сервисов, которые вы делаете для небольшой аудитории или для портфолио чтобы показать кому-то по случаю. (кстати напишите в комментариях интересно ли вам было бы чтобы я сделал подробную инструкцию по разработке и деплою подобного приложения)

Результаты и графики

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

В целом же оценка увеличения опж как у мужчин так и у женщин сильно варьирует в зависимости от страны и возраста, но в первые 40 лет жизни не слишком изменяется, находясь в интервале 5.87 (q05=4.09, q95=8.09) лет, зато начиная с 40 лет стремительно начинает падать снижаясь к 80 годам более чем вдвое до 2.51, (q05=1.68, q95=3.43) соответственно. Что в целом логично ведь людей, имеющих факторы риска, связанные с плохими привычками и нездоровым образом жизни до такого возраста, доживает гораздо меньше. Вывод, если вам 40 лет – самое время «закрыться с прибылью» и начать вести здоровый образ жизни прямо сейчас, позже может быть уже поздно.

Интересные графики также получаются если добавить к данным разметку стран по уровню дохода от всемирного банка и отобразить каждую страну в координатах, где по горизонтали будет лежать текущая продолжительность жизни при рождении, а по вертикали полученная оценка увеличения продолжительности жизни при исключении управляемых факторов риска. Очередная иллюстрация классического «Все счастливые семьи похожи друг на друга, а каждая несчастливая семья несчастлива по-своему.»

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

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

Взглянем еще и на сравнение между среднемировыми мужчинами и женщинами по вкладам факторов риска в оценку увеличения продолжительности жизни. В целом у обоих полов основную и примерно одинаковую долю занимают метаболические и пищевые факторы риска но у женщин гораздо больший вклад от исключения небезопасного секса – 7% против 3.2% у мужчин, а у мужчин бросаются в глаза в разы большие доли вкладов при исключении употребления алкоголя и табака –  7.9% против 2.1% и 16% против 6.4% соответственно. Выводы делайте сами.

Обработка данных и немного популярной популяционной статистики

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

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

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

Например, упрощено возьмем что коэффициенты смертности начинаются с 0.01 и увеличиваются на 0.01 на протяжении 100 лет. Таким образом если в возрасте 0 лет у нас было 100.000 людей то до возраста 1 доживет уже 100.000 – (100.000 * 0.01) =  99.000, тогда до следующего возраста доживет уже 99.000 – (99.000 * 0.02) = 97.020 и так далее до возраста 101 до которого уже не доживет ровно 0 статистических существ т.к. коэффициент смертности в 100 лет станет равным 1.

Далее мы считаем сколько человеко-лет было прожито в каждой возрастной группе, например от 0 до 1 года у нас умерло 1000, значит 99.000 человек прожили полный год в этом возрасте а из тысячи тех, кому не повезло будем считать, что они умирали в течении года равномерно и в среднем тогда получается, что они прожили в этом возрасте полгода (кто-то умер в начале года, а кто-то в конце, находим среднее) итого 99.000 + 1000 / 2 = 99.500 человеко-лет для возраста 0. Так повторяем для каждого возраста.

def life_expectancy_from_population_and_deats(     data: pd.DataFrame,     age_group_start_column: str,     deaths_column: str,     population_column: str,     radix: int=100_000,     last_age_group_years: int=5, ) -> pd.DataFrame:     """     calculating life expectancy by population and deaths     based on guideline     https://www.ons.gov.uk/peoplepopulationandcommunity/healthandsocialcare/healthandlifeexpectancies/methodologies/guidetocalculatingnationallifetables     """      life_table = data.copy()     life_table.sort_values(by=age_group_start_column, inplace=True)      # Calculate q_x - likelihood or risk of death having reached age x     life_table['q_x'] = (        life_table[deaths_column].values         /         (             (                 0.5                 *                 life_table[deaths_column].values             )             +             life_table[population_column].values         )     )      # Calculate l_x - number of people surviving to age x     life_table['l_x'] = np.nan     life_table.loc[life_table.index[0], 'l_x'] = radix      for i in range(1, len(life_table.index), 1):         life_table.loc[life_table.index[i], 'l_x'] = (             life_table.loc[life_table.index[i - 1], 'l_x']             -             (                 life_table.loc[life_table.index[i - 1], 'l_x']                 *                 life_table.loc[life_table.index[i - 1], 'q_x']             )         )      # Calculate L_x - the number of person years lived at each individual age group     life_table['L_x'] = np.nan      for i in range(0, len(life_table.index) - 1, 1):          curr_age_group_years = (             life_table.loc[life_table.index[i + 1], age_group_start_column]             -             life_table.loc[life_table.index[i], age_group_start_column]         )          current_age_L_x = (             life_table.loc[life_table.index[i], 'l_x']             +             life_table.loc[life_table.index[i + 1], 'l_x']         )          life_table.loc[life_table.index[i], 'L_x'] = curr_age_group_years * (current_age_L_x / 2)      life_table.loc[life_table.index[-1], 'L_x'] = (         last_age_group_years * (life_table.loc[life_table.index[-1], 'l_x'] / 2)     )      # Calculate T_x - total number of years lived     life_table['T_x'] = np.nan      for i in range(0, len(life_table.index), 1):          curr_age_group_sum = life_table.loc[life_table.index[i]:, 'L_x'].sum()          life_table.loc[life_table.index[i], 'T_x'] = curr_age_group_sum      # Calculate E_x - period expectation of life at exact age x     life_table['E_x'] = (         life_table['T_x'].values         /         life_table['l_x'].values     )      return life_table  

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

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

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

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

Валидация результатов и встреча с хаосом

Чтобы проверить совпадут ли результаты моих расчетов с ожидаемой продолжительностью жизни уже рассчитанной авторами исследования я взял исходные данные сайта предоставляющего доступ к данным исследования Global Burden of Disease https://vizhub.healthdata.org/gbd-results/ Выбрав смертность с разбивкой по полу и возрасту для 204 стран я пересчитал ожидаемую продолжительность жизни. Когда я построил гистограмму распределения средней абсолютной ошибки по странам и по полу между рассчитанным мною значением и оригинальным, я был озадачен:

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

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

Заключение

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

Кстати если вас интересует тема продления жизни присоединяйтесь к сообществу активистов https://openlongevity.org/ продвигающих данное направление на всех уровнях от научных разработок до привлечения инвестиций и подготовки общественного мнения, у ребят также есть русскоязычный канал в телеграмме: t.me/LifeExtensionForum (https://t.me/LifeExtensionForum) и куча интересных проектов.

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

Ссылки

1. Исследование Global Burden of Disease

2. Репозиторий с кодом дашборда

3. Репозиторий с кодом обработки данных и дебагом графиков

В блоках управления заброшенных электросамокатов Spin в Сиэтле энтузиасты обнаружили рабочие платы на базе Raspberry Pi 4B. Пока неясно, можно ли эти микроконтроллеры официально изымать из никому ненужных скутеров, которые просто валяются в городе в отключённом режиме уже несколько месяцев.

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

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

Исследователи выяснили, что в управляющем внешнем блоке Spin установлена плата Raspberry Pi 4B. Некоторые из них считают, что с юридической точки зрения, если скутеры брошены и отключены от сети, то вскрыть их устройство и вытащить рабочий микроконтроллер для дальнейшего использования не является нарушением закона. В настоящее время неясно, планирует ли Spin забрать свои оставшиеся активы в городе. Любители электроники в США из других городов даже заинтересовались турами в Сиэтл для охоты за Raspberry Pi 4B и другими компонентами в брошенных самокатах Spin. Скутеры уже некоторое время не отображаются на карте в приложении, так что их можно найти только при обследовании местности.

Судя по фото, корпус даже не разбирали аккуратно, а сломали, оторвав стойки креплений.

1 августа компания Авито поставила оформленных в Армении сотрудников перед выбором: либо понижение зарплаты на 30-40%, либо увольнение с компенсацией за 1 месяц работы. Вот история одного из сотрудников.

Я перевелась в Армению в сентябре 2022. Переезжать надо было в любом случае — работа мужа не готова была продолжать сотрудничество с теми, кто оставался в России. И изначально «Кех Армения» позиционировался как выход из такой безвыходной ситуации.

Условия звучали нормально: зарплата конвертировалась NET to NET по внутреннему курсу компании, который был чуть выше курса ЦБ. Потом они начали меняться. Сначала в декабре всех перевели на VAT to VAT — разница между российским НДФЛ 13% и армянским 20% вычиталась из зарплаты «на руки». В апреле изменился внутренний курс. В мае я получила прибавку к зарплате, на которой сказалось и то, и другое. Если в рублях сумма  звучала неплохо, то после вычета дополнительных 7% и пересчёта зарплаты по новому курсу прибавка получилась не особенно большой.

В июле пришла коммуникация о снижении премий. Теперь за сверхрезультат вместо 100% зарплаты компания обещала около 70%. Объяснялось это справедливостью по отношению к тем, кто работает в российских юрлицах и получает зарплату в рублях. Казалось, что на этом всё — дальше только закрытие «Кех Армении» и сокращение всех сотрудников. Но компания оказалась коварнее.

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

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

Группа работников будет оспаривать законность действий компании. Мы же будем следить за событиями и публиковать новости в нашем telegram-канале. Если вы работник Авито в Армении или столкнулись с подобной ситуацией на своей работе, пишите в наш telegram-бот.

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

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

Немного обо мне

Пару слов о себе, чтобы вы понимали, с кем имеете дело, прежде чем начнете читать сам отзыв. 

• Меня зовут Роман Суранов, мне 31 год (ого, уже?!)

• Окончил Московский институт электронной техники по специальности «инженер-электронщик интегральных электронных микросхем».

• Работаю в IT около 10 лет. Сначала пару лет фрилансил, будучи студентом, потом пошел веб-разработчиком на первую работу в офис — и понеслось. 

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

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

Тогда уже второй год в стране проводилось ЕГЭ, и поступали в институты по его результатам. Наилучшим образом я сдал как раз информатику, но пошел изучать физику (как видите, уже тогда с логикой были некоторые проблемы…)

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

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

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

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

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

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

Так и начался мой путь в IT. Почему же я решил пойти учиться на онлайн-курсы в Яндекс Практикум?

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

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

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

В итоге в процессе самообучения я осознал три проблемы, а именно:

1. Отсутствие знающего и опытного профессионала рядом, который всегда подскажет, «как правильно»;

2. Не структурированная и разношерстная информация;

3. Отсутствие ответственности за результат и невозможность услышать мнение со стороны.

Выбор курса для обучения

Решением этих трех проблем были онлайн курсы. Я занялся поиском провайдера, чтением отзывов и выбором курса. Помню, тогда выбирал из двух вариантов, это был Hexlet и Яндекс Практикум. Эти две онлайн школы по отзывам внушали доверие, но цены, конечно, отпугивали.

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

Почему именно его? Моим основным языком программирования был PHP, а Python как раз начинал сильно набирать популярность из-за своей универсальности, что в свою очередь было слабой стороной «пыхи» (создан и используется для разработки веб-приложений). Были мысли поменять стек и пересесть на «питона», да и просто посмотреть в чем отличия, какие подходы и практики используется в другом языке, для расширения IT-кругозора.

Курс №1 – «Python разработчик»

Любой курс в Яндекс Практикуме начинается с вводной бесплатной части. Она рассчитана часов на 20. За это время твоя задача понять: «а надо ли оно тебе вообще?». На этом этапе обычно у всех вагон мотивации — и мы точно уверены, что легко преодолеем все преграды на пути к диплому. Хочу заранее предостеречь читателя от этой уверенности, потому что меня она в итоге и погубила (и не только меня).

Если смотреть состав тем курса Яндекс Практикума, то можно сразу сказать, что они подобраны грамотно и вполне учитывают современные веяния в backend-разработке. На изучение каждой темы в Яндекс Практикуме дается 2 недели – равные одному спринту (чувствуете запах Agile). Неделя – на изучение теории в текстовом формате и работу в тренажере кодинга, и неделя — на выполнение практического задания, которое проверяет наставник на кодревью.

Обучение в Яндекс Практикуме начинается с добавления тебя в группы твоей когорты в корпоративном мессенджере «Пачка» – российский аналог Slack. Там ты знакомишься со своими наставниками и куратором. Эти люди будут сопровождать тебя на протяжении всего курса и помогать пройти этот сложный путь в разработчики.

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

Первые шесть спринтов в Яндекс Практикуме дались мне довольно просто. Но нужно понимать, что я уже работал backend-разработчиком четыре года. Обучение не вызывало каких-то трудностей, и каждый спринт я закрывал до дедлайна. В описании курса Практикума написано, что на обучение у студента будет уходить в среднем 15 часов в неделю. У меня примерно столько и уходило, возможно чуть меньше, но опять же, уже тогда я был далеко не новичок.

У новичков в IT на курсе уходило как минимум в два раза больше времени. Если вы пришли в Яндекс Практикум с целью смены профессии, либо просто только начинаете свой путь — будьте уверены, эта учеба станет полноценной работой. Да, материал в Практикуме излагается довольно кратко, не отвлекаясь на детали — но с учетом того, сколько еще придется изучать самому, объем получается очень большим.

Примерно к десятому спринту, несмотря на то, что для меня само понимание материала не вызывало трудностей — я выгорел. Совмещал работу (разработчиком) с учебой (на разработчика) — и поэтому у меня не оставалось свободного времени. Силы меня покинули, и было два выхода – либо уходить в академ (взять официальный перерыв от учебы и вернуться позже), либо отчисляться из Практикума. Я выбрал второе. Посчитал, что достиг своей цели в понимании нового для себя языка программирования, узнал много нового — и на этом можно остановиться. Какой отзыв имеем в сухом остатке:

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

• + Несколько раз общался с наставниками, которые работали в крупных IT-компаниях, также подчеркнул несколько важных вещей. Услышал мнение со стороны о своем коде и получил объективную оценку.

• – Объем материалов в Практикуме большой, и успевать делать все в дедлайны очень тяжело. С учетом того, что курс длится 9 месяцев, пройти его удастся самым упертым и замотивированным. У меня вот не получилось, но я сделал выводы. Все-таки прохождение столь долгого курса – это не спринт, а марафон, и силы нужно распределять на всю дистанцию равномерно.

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

Курс №2 – «Алгоритмы и структуры данных»

Через некоторое время я увидел, что у Яндекс Практикума начали появляться курсы для разработчиков с опытом. Один из них — «Алгоритмы и структуры данных», продолжительностью четыре месяца. Его основой была именно практика. Для прохождения необходимо решить от 60 до 100 задач, плюс теория. Всего восемь спринтов.

Для решения задач ты должен владеть одним из предлагаемых языков программирования, php в списке не было — и тут мне пригодились знания из предыдущего курса – по Python. 

Обучение на этом курсе устроено следующим образом: каждый спринт длится также две недели, неделя на изучение теории и неделя на решение задач. Для сдачи спринта нужно решить хотя бы половину задач по теме в тренажере «Яндекс Контекст» (в среднем их по 12 в каждой теме) и две отдельных задачи, которые отправляешь на код-ревью наставнику.

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

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

• + У нас был очень хороший наставник. Всегда помогал и объяснял непонятные вещи. Видно, что опытный разработчик, который на алгоритмах “собаку съел”.

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

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

• – Главный минус (если это можно так назвать) – это сложность. В нашей когорте были только опытные разработчики и было видно, что тяжело идет у всех 🙂  Этот курс Практикума составлялся таким образом, чтобы в неделю уходило в среднем 15-20 часов на изучение. У меня же бывало на одну задачу уходило только восемь 🙂 Потом оказалось, что я был такой не один — и у многих ситуация похожая. Но, опять же, я всегда старался до самого конца решить задачу сам — и не просил помощи у наставника. Но это стоило мне огромных усилий и кучу потраченного времени. Учтите этот момент — и закладывайте как минимум в два раза больше времени на обучение.

Курс №3 – «Продвинутый Go-разработчик»

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

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

• + Первые два курса Практикума по своему наполнению теорией и практикой очень понравились. Наставники — хорошие ребята, но все же чувствовался дефицит экспертов в этом направлении (если, например, сравнивать с Python). Не всегда можно было получить грамотную помощь в мессенджере от менторов. Но, учитывая, что курс рассчитан на опытных разработчиков, это не критично. 

• + Интересная концепция дипломных проектов. После второго и третьего курса ты пишешь по сути проект с нуля, который потом можешь положить себе на гитхаб.

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

Есть ли жизнь после курсов Практикума?

В общей сложности на прохождение трёх курсов в Практикуме я потратил 16 месяцев. За это время меня два раза повысили на работе — и теперь я уже не разработчик, как обозначал вначале статьи, а архитектор ПО. Связаны ли повышение и обучение? Я думаю, да — Практикум наверняка внес свою лепту. Но нужно помнить, что никаких гарантий никто вам дать не сможет; все, как всегда, зависит только от вас. Выбирая обучение в Яндекс Практикуме, рассчитывайте свои силы верно! Иначе словите пару выгораний, как я, и несколько порывов все бросить и уйти в закат. 

Но одно в этом отзыве могу сказать однозначно – после любого курса в Яндекс Практикуме вы уже не станете прежним. Это выход из зоны комфорта, а значит — рост и развитие.

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

Иногда возникает необходимость получить доступ к сайтам, например, https://refactoring.guru или https://leafletjs.com, но по каким-то причинам эти сайты заблокирован в вашей стране. А может быть вы просто хотите получить доступ к сайтам, которые доступны только по IPv6, а ваш провайдер не предоставляет вам такой возможности. Одним из выходов может стать VPN. Однако покупать VPN где-то на стороне при наличии собственного VPS сервера, где интернет работает нормально, просто лишняя трата денег. В таком случае возникает вопрос: а как, собственно, организовать этот самый VPN? В интернете есть множество инструкций, но они обычно не затрагивают тему протокола IPv6 или затрагивают, но там используются спорные решения.

Одним из популярных вариантов организации VPN является Wireguard. Сам по себе, Wireguard, довольно прост, но при этом его можно использовать в любых схемах: «точка-точка», «звезда» и даже mesh-сеть. В дальнейшем будет использоваться схема «звезда», которая подразумевает использование отдельного сервера и наличие, минимум, одного или нескольких клиентов.

Если с IPv4 всё понятно, поскольку большинство руководств сходятся к решению с использованием серой адресации с организацией NAT на сервере. По сути, это стандартная схема для IPv4 адресации. Адресов IPv4 мало и стоят они дорого, поэтому никто, в здравом уме, не будет использовать «белые» адреса непосредственно на устройствах, если, конечно, это не сервер, который доступен в интернете. А вот с IPv6 не всё так однозначно.

Сам по себе протокол IPv6 строится на том, что никому не потребуется использовать NAT. При этом, это не означает, что сам по себе NAT в IPv6 недоступен. NAT для IPv6 доступен (обычно его называют NAT66), но его использование не рекомендуется, а в некоторых случаях это даже вредно. К тому же всегда есть возможность его не использовать, в противовес IPv4.

Выдавать IPv6 адреса хостинг-провайдеры могут по разному:

1. Выдача IPv6 адресов поштучно. Самый странный вариант. Если у вашего хостинг-провайдера так, то, скорее всего, стоит просто сменить его на другого, даже к контексте использования VPS для обычного сервера, не говоря уже об использовании как VPN. С некоторой долей вероятности тоже можно получить VPN с IPv6, но далее этот вариант просто не рассматривается. После прочтения материала вы сами сможете понять что вам нужно делать, если вы всё-таки решитесь использовать подобного провайдера.

2. Выдача сети /64. Наиболее часто встречающийся вариант для мелких провайдеров. Иногда есть возможность через поддержку получить сеть /63 или, даже, ещё большего размера, что будет рассмотрено в следующем варианте. Наличие только /64 не самый хороший вариант для VPN, но с ним уже можно работать.

3. Вариант не особо отличается от предыдущего, но вместо сети /64 вам выдают сеть большего размера (до /48), т.е. в вашем распоряжении оказывается адресация некоторого количества сетей /64. Например при /48 — 65536 штук.

4. Маршрутизация определённого префикса IPv6 на вашу виртуальную машину. Самый редкий вариант среди мелких провайдеров, в публичном доступе такое почти не встречается, но, возможно есть возможность получить префикс через техническую поддержку. Этот вариант подразумевает, что ваш хостинг провайдер прописал маршрут на ваш виртуальный сервер для выделенного вам префикса. Вам может быть выдана сеть от /64 до /48, которые без костылей могут быть использованы вами для организации VPN.

Сложность настройки VPN постепенно уменьшается от 1 до 4 варианта, поэтому начнём с 4 варианта и постепенно поднимемся вверх.

Шаг 1: Включение маршрутизации на сервере VPN

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

Для IPv4 маршрутизация включается с помощью sysctl путём установки

net.ipv4.ip_forward=1

Для IPv6 это делается аналогично:

net.ipv6.conf.all.forwarding = 1

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

net.ipv6.conf.ens3.accept_ra = 2

В данном примере `ens3` — это сетевой интерфейс нашего VPS, откуда мы хотим принимать анонсы маршрутизатора. На большинстве хостингов назначение IPv6 адресов на VPS производилось путём ручной настройки, а значит и принимать RA не требуется, т.е. данную настройку можно пропустить.

Теперь осталось выделить сеть /64 из доступного вам диапазона, назначить один из адресов на интерфейс Wireguard на VPS, а также выдать каждому клиенту по IPv6 адресу из этого же диапазона. Всё прописывается в конфигурации сервера и клиентов. На этом настройка VPN для 4 варианта будет закончена.

Шаг 2: Обеспечиваем маршрутизацию пакетов для сервера без выделенного префикса

Теперь перейдём к варианту, когда нам выделено, в лучшем случае, от /63 до /48, в худшем /64. Сначала рассмотрим лучший вариант.

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

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

Поскольку мы назначили для своего сервера сеть /64, то при попытке маршрутизатора провайдера найти соседа с адресом, который не попадает в данную подсеть, наш хост будет эти запросы игнорировать. Чтобы этого не происходило, можно воспользоваться специальной службой NDP proxy. Этот служба может пересылать запросы на поиск соседей и возвращать ответы и отвечать на указанные запросы положительным ответом. К сожалению, Wireguard работает на более высоком сетевом уровне, поэтому единственным вариантом для нас является просто выдача положительных ответов при запросе адресов, которые используются в VPN.

Одним из вариантов решения задачи — это установка пакета ndppd. Пакет точно доступен в стандартных поставках Ubuntu и Fedora в официальных репозиториях. Установите его с помощью вашего пакетного менеджера. Конфигурация ndppd достаточно простая. Файл конфигурации сервиса расположен по адресу /etc/ndppd.conf. Содержимое этого файла должно быть примерно таким:

proxy ens3 {
rule 2001:0db8:827:fcde:cafb:073d:a65e:25b0 {
static
}
}

Данная конфигурация означает, что если приходит запрос на интерфейс ens3 с запросом соседа по адресу 2001:0db8:827:fcde:cafb:073d:a65e:25b0, то необходимо ответить, что это наш адрес. Записи rule можно повторить несколько раз и, даже, указать в каждой записи не отдельный адрес, а целый диапазон. Однако сам ndppd не приветствует широкую маску сети. Если клиентов VPN немного, лучше для каждого из них создать свою запись.

Шаг 2.1: Что делать, если у нас только сеть /64

Это самый неблагоприятный вариант, но при этом мы всё равно сможем обеспечить работу нашего VPN. Вообще, сама идея разделять диапазон /64 на сети меньшего размера, мягко говоря, не приветствуется. Но поскольку у нас нет другого выхода, то придётся это сделать.

Поскольку мы используем VPS, то вряд ли будем использовать механизм SLAAC, который работает только с сетями /64. К тому же, в большинстве случаев, адресация для VPS прописывается вручную, просто потому, что у сервера должен быть строго определённый адрес. Исходя из этого можно разделить сеть /64 на сети меньшего размера. Как делить? Если вы не планируете запускать на сервере другие сервисы VPN, то одним из вариантов являются сети /65, т.е. сеть /64 мы делим пополам. В этом случае для клиентов VPN нам доступны почти все биты из диапазона /64, кроме старшего. При таком разделении наш адрес будет выглядеть как обычный адрес, который, например, мог бы быть выделен через SLAAC.

Если кроме Wireguard вы хотите, например, также запустить на вашем сервере ещё и OpenVPN, то вам может понадобиться ещё одна сеть для этого сервиса. В таком случае вы можете выбрать сеть /66. Конечно, в этом случае вам нужно учитывать уже не один старший бит, а два. Можно и дальше сужать сети, но при этом адреса ваших клиентов будут уже не так похожи на адреса, которые обычно выделяются при использовании механизма SLAAC. Вариант отличные от /65 вы можете организовать самостоятельно.

Чтобы ваш сервер обеспечил маршрутизацию пакетов, которые необходимо будет отправить клиенту VPN, необходимо урезать сеть в настройках сетевого интерфейса. Вместо /64 указываем выбранную маску, например, /65. После этого настройка вашего VPN сервера не отличается от настроек, которые мы делали на шаге 2. Конечно, маску /65 нужно указать и в настройках Wireguard на вашем сервере.

Практическая часть

Дабы не вдаваться в подробности, будем считать, что вы ознакомились с моей «Шпаргалкой по Wireguard» или любой другой инструкции, которых очень много в интернете, и вам не надо объяснять как генерировать ключи.

Включаем маршрутизацию на VPS путём установки параметров, например, путём добавления файла /etc/sysctl.d/20-vpn.conf и загрузки их через sysctl -p или путём перезагрузки VPS:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding = 1

Сгенерируйте пару ключей для своего VPN сервера, например так

wg genkey | tee private.key | wg pubkey > public.key

Для дополнительной безопасности для каждого клиента может быть сгенерирован ключ PSK, но это не обязательно:

wg genpsk > psk.key

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

[Interface]
Address = 192.168.0.1/24, 2001:0db8:827:fcde::1/64
PrivateKey = <SERVER_PRIVATE_KEY>
ListenPort = <SERVER_PORT>

[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 192.168.0.2, 2001:0db8:827:fcde::1ce:1ce:babe
PresharedKey = <PRESHARED_KEY>

Не сложно догадаться, что <SERVER_PRIVATE_KEY> — это закрытый ключ сервера, а <CLIENT_PUBLIC_KEY> — это публичный ключ клиента. 192.168.0.0/24 — это сеть IPv4 для нашего подключения, а адрес 192.168.0.1 будет присвоен интерфейсу Wireguard. По аналогии, 2001:0db8:827:fcde::/64, соответственно сеть IPv6, а адрес 2001:0db8:827:fcde::1 — адрес интерфейса Wireguard. Опция PresharedKey не обязательная, но если она указана на сервере, то она также должна быть указана в конфигурации клиента, значение ключей на сервере и клиенте должно совпадать.

Секция [Peer] должна быть создана для каждого клиента. В AllowedIPs должны быть указаны IP адреса и сети, которые мы ожидаем от клиента.

Конфигурации клиентов должны иметь вид

[Interface]
Address = 192.168.0.2, 2001:0db8:827:fcde:beef:1ce:1ce:babe
PrivateKey = <CLIENT_PRIVATE_KEY>

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
AllowedIPs = 0.0.0.0/0, 2000::/3
Endpoint = <SERVER_NAME>:<SERVER_PORT>
PresharedKey = <PRESHARED_KEY>
PersistentKeepalive = 20

Аналогично, на клиенте: <CLIENT_PRIVATE_KEY> — закрытый ключ клиента, <SERVER_PUBLIC_KEY> — публичный ключ сервера. В Endpoint необходимо указать адрес <SERVER_NAME> и порт <SERVER_PORT> сервера, которые соответствуют указанным параметрам в настройках сервера. Параметр PresharedKey должен присутствовать, если он есть в секции [Peer] для этого клиента, содержимое ключа должно совпадать.

PersistentKeepalive может также отсутствовать. Но если указано, то клиент каждое указанное количество секунд будет отправлять пакет данных. Это полезно в тех случаях, когда клиент находится за NAT или Firewall, которые при отсутствии активности могут запретить удалённому хосту присылать вам ответы.

Чтобы обеспечить доступ клиентов в интернет по протоколу IPv4, необходимо включить NAT, например, с помощью скриптов, которые необходимо добавить в секцию `[Interface]` на сервере, и отключить их, если клиенты отключаются.

PostUp = iptables -A FORWARD -i %i -j ACCEPT -w 10; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE -w 10
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE

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

Конечно, делать все необходимые настройки руками, особенно если новый клиент вашего VPN появляется не часто, это просто сущее наказание. Поэтому я задумался об автоматизации. В качестве базы был найден скрипт nebulakl/wireguard-config-generator. Он не совсем подходил под мои нужды, поэтому я его переделал и выложил в fsa/wireguard-config-generator.

Скрипт позволяет генерировать конфигурацию для сервера VPN на базе Wireguard. Далее можно генерировать необходимое количество конфигураций клиентов. Скрипт сохранил возможность использования NAT66, как было в оригинальном скрипте, но включение NAT66 производится явно через редактирование конфигурации сервера. По умолчанию скрипт использует «серую» адресацию, как в оригинальном скрипте.