DNS
С гугл-DNS что-то у всех происходит или искать локальные проблемы? пока четыре восьмерки стояли единственным, вообще ничего не открывалось со вчерашнего вечера
Лига Сисадминов
2 691 пост
•
19 152 подписчика
0 просмотренных постов скрыто
Как я хотел сэкономить 15 минут на хоумлабе, а в итоге дебажил Cloudflare
Схема стандартная: мне нужно было выкатить наружу очередной сервис из своего хоумлаба (дашборд Grafana, внутреннее API, музыкальный сервер - неважно). Я открывал админку Cloudflare, создавал туннель, прописывал DNS-запись, настраивал политики Zero Trust Access, копировал ID туннеля, генерировал конфиг, устанавливал службу на сервер и со спокойной душой закрывал вкладку. Первые несколько раз меня это вообще не парило.
Примерно на пятом сервисе до меня дошло: я больше не настраиваю инфраструктуру. Я исполняю ритуал.
И я задался вопросом нафига я вообще это делаю руками? У Cloudflare есть отличный API. Всё, по чему я кликаю мышкой в красивом (не очень) интерфейсе, в конечном итоге превращается в обычный HTTP-запрос. Так почему весь этот адский воркфлоу нельзя упаковать в одну единственную команду?
Так родился проект cfzt.
Изначально это не планировалось как какой-то коммерческий продукт или крутой опенсорс. Мне просто хотелось перестать страдать фигнёй по выходным.
Идеальная цель выглядела так:
zt up grafana 3000
И всё. За этими четырьмя словами утилита сама создаёт туннель Cloudflare, настраивает правила ингресса, регистрирует DNS, вешает авторизацию через Zero Trust Access, ставит демона в систему и запоминает состояние, чтобы потом всё это можно было чисто удалить одной командой.
Команда выглядит крошечной. Объём работы под капотом - огромный. И, как выяснилось позже, это была самая простая часть.
Процесс от init до поднятия туннеля
Дело было не в Cloudflare
Самое забавное, что я вообще не пытался заменить Cloudflare. Скорее наоборот.
Cloudflare Tunnel - это одна из тех штук, которая при первом знакомстве кажется чистой магией. Твой сервер может сидеть за NAT, за жёстким провайдерским CGNAT, вообще где угодно, но он всё равно будет доступен из интернета без единого открытого входящего порта на роутере.
Добавь сверху zero trust - и бах! Каждый твой внутренний сервис по дефолту защищён нормальной авторизацией, привязан к identity-провайдеру и еще сертификат насыпают на сдачу.
База просто монументальная. Проблема была во всём том, что её окружало. Каждый новый чих требовал повторения одного и того же алгоритма:
- Создать туннель.
- Прописать DNS-запись.
- Настроить Ingress rule.
- Создать приложение в Access.
- Привязать к нему политику доступа.
- Сгенерировать конфигурационный файл.
- Установить системную службу на сервере.
- Запустить её.
Ни один шаг сам по себе не сложен. Они просто… нудные. И хуже всего была даже не потеря времени, а ментальная нагрузка. А я точно создал DNS? А access включить не забыл? Какой туннель держит этот домен? А если я его удалю, ничего не сломается?
В хоумлабе и так хватает хаоса, чтобы ещё держать в голове весь этот чек-лист деплоя.
И я подумал: а что, если бы публикация сервиса в сеть была такой же простой, как запуск Docker-контейнера?
Docker внутри устроен невероятно сложно, но его интерфейс скрывает весь этот ужас от пользователя. Ты пишешь команду - Docker разбирается со всем остальным. Это и стало главной фишкой cfzt: не плодить миллион галочек и настроек, а сделать стандартный путь банальным и скучным.
За одной строчкой скрывается куча работы с API, но пользователю до этого не должно быть никакого дела. Сложность должна оставаться внутри инструмента. Мне кажется, создателям современного софта для инфраструктуры стоит почаще выбирать именно такой подход.
Фича, которую никто не заметит
Ирония в том, что больше всего я горжусь функцией, которую пользователи, надеюсь, никогда не увидят. Это роллбэк или откат по-нашему.
Инструменты автоматизации обожают ломаться на середине пути. То API Cloudflare выдаст rate limit, то сессия протухнет, то один запрос пройдёт, а следующий за ним упадет с ошибкой. В итоге у вас остаётся полурабочее нечто:
- Туннель вроде создался, но до него не достучаться.
- DNS-запись смотрит в никуда.
- В панели access висит приложение для сервиса, которого уже нет.
Убирать это дерьмо руками несложно, но выбешивает знатно.
Я хотел, чтобы cfzt работал иначе. Любой деплой - это транзакция. Если все шаги прошли успешно - сервис онлайн. Если споткнулись хоть на одном этапе - утилита автоматически сносит всё, что успела насоздавать до этого момента. Никаких осиротевших ресурсов и никакого гадания в веб-морде Cloudflare, что там надо подчистить.
Звучит очевидно? Да. На практике же пришлось детально логировать каждый чих к API, записывать ID каждого созданного ресурса и писать под них логику удаления. Зато теперь я могу запускать утилиту и не бояться, что она оставит после себя кучу мусора. Лучший откат - это тот, о котором тебе не пришлось думать.
Но откат шага в своей проге это не то же, что откат на стороне cloudflare...
А потом я почитал логи...
В какой-то момент проект дошёл до стадии, когда пилить фичи надоело и я начал просто пользоваться утилитой каждый день. Вот тут-то и полезли самые интересные артефакты.
Как-то вечером после очередного деплоя я заглянул в логи и заметил странное: cloudflared (официальный демон Cloudflare) внезапно переключился с протокола QUIC на старый добрый HTTP/2.
Вообще, это штатное поведение. QUIC работает поверх UDP, и если с UDP что-то идёт не так (роутер ребутнулся, Wi-Fi мигнул, провайдер решил подрезать пакеты) - туннель автоматически падает в фоллбэк на HTTP/2 поверх TCP, чтобы связь вообще не оборвалась.
Странно было другое. Он никогда не переключался обратно.
Подождите... Это что, навсегда?
Сначала я подумал, что чего-то не понимаю в работе туннелей. Ну, наверное, он проверяет сеть раз в пару минут? Или есть скрытая настройка?
Я сидел и караулил логи. Прошёл час, два. Туннель работал идеально, трафик шёл, но намертво сидел на TCP.
Я перерыл официальную документацию - тишина. Пошёл штурмовать гитхаб. И бинго! Нашёл старый тикет, где чувак жаловался ровно на то же самое. Логика у демона Cloudflare простая: если туннель один раз упал в HTTP/2, он больше никогда не попытается вернуться на быстрый QUIC. Только если полностью перезапустить сам процесс ручками. И баг этот висел в issues в официальном репозитории уже очень давно.
Выбора было два: либо смириться и ждать, пока пацаны из Cloudflare это починят (спойлер: можно не дождаться), либо костылить обходной путь. Я выбрал второй вариант.
Пишем вочдог вместо патча
Лезть в исходники самого cloudflared, форкать его и пересобирать сетевой стек ради одного бага - так себе идея. Поэтому я посмотрел на задачу проще: какие данные у меня реально есть на руках?
Ответ оказался банальным: при переходе с QUIC на HTTP/2 демон пишет в stderr конкретную строчку. Всё, это и есть наш API! Зачем анализировать пакеты или пинговать порты, если можно просто читать логи процесса?
План получился такой: cfzt запускает туннель и начинает грепать его логи на лету. Как только ловим строчку о фоллбэке, запускается таймер. Мы не рубим процесс сразу - вдруг сеть ещё штормит. Выжидаем паузу, и если туннель всё ещё на HTTP/2 - тихонько дергаем службу.
При перезапуске cloudflared снова пытается инициировать модный QUIC. Если UDP всё ещё лежит - ок, он опять упадёт в HTTP/2. Наш вочдог это увидит и увеличит таймер ожидания: 10 минут, 20, 40... В итоге шаг баг-оффа упирается в 1 час. Мы не боремся с сетью, мы просто даём туннелю шанс очухаться, когда шторм пройдёт.
Выглядит этот «инженерный фикс» до смешного просто. Вот кусок кода на Go, который закрыл эту проблему раз и навсегда:
// Строка, которую выплёвывает Cloudflare, когда сдается и уходит на TCP
const FallbackSignal = "Failed to connect to the edge over QUIC, falling back to HTTP2"
func watchTunnelLogs(scanner *bufio.Scanner, restartTrigger chan<- bool) {
backoff := 5 * time.Minute
for scanner.Scan() {
line := scanner.Text()
if strings.Contains(line, FallbackSignal) {
log.Warn("Обнаружен откат с QUIC на HTTP/2. Запускаем вочдог.")
// Ждём, пока сеть стабилизируется
time.Sleep(backoff)
// Триггерим мягкий перезапуск процесса
restartTrigger <- true
// Экспоненциальный шаг ожидания (максимум до 1 часа)
backoff = min(backoff * 2, 1 * time.Hour)
}
}
}
Решение не претендует на учебники по Computer Science, но оно работает. Теперь, если посреди ночи роутер решит обновиться, утилита подхватит этот момент, переждет грозу и молча вернет туннель на быстрый протокол.
Чему меня научил этот проект
Я начинал писать эту утилиту просто потому, что мне надоело кликать по кнопкам в браузере. В итоге я несколько недель залипал в жизненные циклы процессов, парсинг логов и логику сетевых фоллбэков.
И в этом вся прелесть создания своих инструментов для автоматизации (переизобретенных велосипедов, если хотите). Ты берёшь мелкую бытовую проблему, думаешь: да ладно, сейчас набросаю тонкую CLI обертку за пару часов в субботу. Но как только ты пытаешься сделать интерфейс по-настоящему простым для пользователя, тебе приходится впитать в свой код всю ту сложность, которую разработчики платформы оставили за бортом.
Ты пишешь транзакционный откат, чтобы не разгребать полуживое состояние руками. Ты пишешь вочдог, чтобы не думать о моргающем интернете.
Интерфейс остается крошечным. Инструмент делает всю грязную работу. Ритуал наконец-то разрушен.
Теперь, когда мне нужно поднять новый сервис, я не открываю пять вкладок в браузере. Я просто пишу в консоли:
$ zt up grafana 3000
✔ Creating Cloudflare Tunnel... Done.
✔ Provisioning DNS records... Done.
✔ Setting up Zero Trust Access policies... Done.
✔ Launching background service with QUIC... Done.
Service is live at https: //grafana. yourdomain. com
И спокойно иду пить кофе. Потому что инфраструктура, черт возьми, должна быть скучной.
Ссылка на проект
Если вам тоже надоел этот бесконечный марафон по дашбордам Cloudflare ради домашнего сервера или стейджинга - проект полностью открыт, пользуйтесь.
GitHub: репозиторий
Буду рад фидбеку. Ломайте, тестируйте, закидывайте ишью или предлагайте фичи. Если утилита сэкономит вам пару минут на выходных - значит, все это было не зря. Только не просите меня добавлять в CLI новые кнопки. Я написал его как раз для того, чтобы их больше никогда не видеть.
Всем удачи!
Показать полностью
1
Удивительное рядом или про рекламу Минцифры на пикабу
Удивительные события всего за пару лет.
Для модераторов: пруф рекламы и переезда рекламы: Куда расти после backend, системного администрирования или Data Science
1. Хабр переходит под контроль модерации минцифры и проходит в шаге от смены названия на "Вестник минцифры"
2. Модераторы минцифры банят налево и направо, за "все по правилам, но обидное". Авторы, кроме копро блогов, заканчиваются.
3. Реальная посещаемость из-за отсутствия контента падает до "около ноля". Накручиваемая и не покупающая аудитория веселится и уходит дальше на Пикабу.
4. Копроблоги переезжают на Пикабу.
5. @ads.news начинает писать на Пикабу рекламу вида "по данным вестника карьеры минцифры, девопс в РФ самый топ, 300 кк\ наносек" .
То, что рынок разработки и девопс в РФ упал в пол настолько, что закончился мойофис и скайенг - не волнует.
И в целом такой подход это хорошо. Чем больше платной рекламы копроблогов переедет от минцифры на пикабу, тем лучше.
Микрометры и космонавтика – или почему 350 нм не является супер лечебной таблеткой
Для ЛЛ: нанометры – это про стоимость изделий, а не только про скорость или космическую магию
В старом тексте про то, что «российский» (по факту скорее белорусский) станочек для микросхем с характеристиками «350 нм», стоящий на складе под чехлом, без расходников, без трафаретов, без персонала, без помещения для установки, скорее всего сгниет так же, как сгнили станки, купленные в 2006 у AMD, появился комментатор с мнением вида «350 нм – то, что надо для космоса, военных, электроники автомобилей, и стиралок». Не знаю, кто и почему не оплатил нормальную консультацию, почему в методичке пишут
а также микроэлектроника для космоса (радиационно стойкие чипы) и военных - как раз и делается вот по таким вот "чугунным" техпроцессам .. профильные издания утверждают..
В чем-то авторы методички правы, для стиралок с двумя реле, как на советской Вятка-автомат (лицензия Candy, Италия), не нужен даже такой. Механического реле времени достаточно.
Для механической системы зажигания достаточно правильно выставленного угла опережения зажигания в трамблере. Там из электроники нужен только импульсный повышающий трансформатор, он же катушка. Хватит даже магнето.
Дальше начинаются нюансы.
Во первых, и это не секрет «специальная» электроника для космоса существует.
Во вторых, и это тоже не секрет, на Марсе успешно отработал (отлетал свое) вертолет Изобретательность (Ingenuity), внутри которого стояла масса бытовой электроники:
Процессор Qualcomm Snapdragon 801 из 2013 года, технология 28 нм.
Инерциальный датчик Bosch BMI-160
Измеритель углов (инклинометр) Murata SCA100T-D02
Датчик высоты Garmin LIDAR Lite v3
И два радиационно стойких контроллера полета (кто напишет в комментариях какие, тот не лентяй)
Если посмотреть историю, то окажется, что
- Американские военные не очень беспокоились про «радиацию», поскольку у ядреной бомбы поражающих факторов хватает и без этого. Беспокоились про световое и ЭМ излучение, самолеты красили в белый, от электромагнитных волн экранировали, но в остальном, после принятия в конце 1970-х, программы «давайте экономить», не помню чтобы как-то специально рассуждали на тему «уууу, радиация».
В 1965 появилась технология Silicon-on-Sapphire, а точнее сразу две - Silicon on Sapphire (SOS) и Closed COS/MOS Logic. Процессор (по современным меркам даже не часы) RCA 1802 выпускался с 1976 по 2022 год, несмотря на свою «отсталость». У Silicon on Sapphire хватает преимуществ, и это не только «радиационная стойкость».
Американские Шаттлы до модернизации летали на новых Intel 8086 и RCA 1802 .
Обсуждать Шаттлы начали в 1967 году, проектировать в 1970, Intel 8086 вышел в 1978, первый полет Шаттла – 1981 год. Intel 80286 вышел только в 1982. Но, память Шаттлов делали на ферритах, для защиты памяти от радиации.
Космический телескоп Хаббл запустили в 1990 году. Изначально там стоял бортовой компьютер «из 1980х» - Rockwell DF-224. В 1993 году туда прикрутили Intel 80386, в 1999 – Intel 80486.
Отказоустойчивость обеспечивалась очень просто – на борту Хаббла было два Rockwell DF-224, в каждом по три компьютерных ядра, тройной набор памяти, итд.
В 1995 году появился компьютер IBM RAD 6000, выпущенный с тех пор огромным (по меркам космоса) тиражом в 200 штук. Технология самого процессора 500 нм. Что скрывается за термином «радиационно-стойкий», сразу не сказать, там не одна технология. Стоит, с учетом инфляции, порядка 300 тысяч долларов за компьютер в сборе.
В 2001 году ему на замену пришел бортовой компьютер от BAE Systems Electronics, Intelligence & Support модели RAD750, выпускавшийся по 250 и 150 нм технологиям.
Это почти тот же IBM, просто часть IBM продали в Loral, Loral был куплен Lockheed Martin, и затем их продали BAE Systems.
Тираж на текущий момент – примерно 150 штук. Не тысяч. Просто штук. В космонавтике с 2005 года.
В 2016 (или 2015) был представлен Bae RAD5500. Технологии 45 нм. По гражданским запускам пока информации нет.
Заключение
Как только кто-то начинает говорить, что «большие нанометры это хорошо для космоса» - это значит, что человек или вообще не разбирается, и не хочет разбираться в предмете, или озвучивает методичку «тяжесть это хорошо, тяжесть это надежно». В космосе есть и 45 нм, и 28 нм.
В космосе используют радиационно-стойкую электронику. Это комплекс мер, включая специальный дизайн, материалы, удвоение и утроение элементов и систем, а не «просто нанометры».
Литература
The CPUs of Spacecraft Computers in Space
Quad-core radiation-hardened system-on-chip power architecture processor, June 2015 DOI:10.1109/AERO.2015.7119114
https://www.researchgate.net/publication/283878871_Quad-core_radiation-hardened_system-on-chip_power_architecture_processor
From Artemis II to deep space: why space-grade chips must be built for the harshest conditions
BAE Systems introduces Ascent™ spacecraft to support space superiority and exploration
NASA to Test Solution for Radiation-Tolerant Computing in Space
Показать полностью
Хорошо, что git всё таки есть (да и вообще svn)
Показать полностью
1
Куда расти после backend, системного администрирования или Data Science
Если вы несколько лет работаете в ИТ и ищете, куда расти, DevOps или MLOps станет следующим логичным шагом. И хорошая новость: не нужно сразу принимать окончательное решение, сначала попробуйте направление на практике.
DevOps: для тех, кто любит работать с инфраструктурой
Если вы привыкли разбираться, как все устроено «под капотом», работаете с серверами, инфраструктурой или backend, DevOps может оказаться вашим вектором развития.
DevOps-инженер отвечает за то, чтобы код быстро, безопасно и предсказуемо попадал в производство: автоматизирует сборку, развертывание, настройку инфраструктуры и мониторинг сервисов.
Здесь пригодятся знания Linux, Docker, CI/CD, Kubernetes, облачной инфраструктуры и автоматизации.
По данным «Хабр Карьеры» на июнь 2026 года, медианная зарплата DevOps-инженера — 249 тысяч рублей. Инженеры с большой экспертизой могут рассчитывать на 378 тысяч, а доходы руководителей направлений превышают 460 тысяч рублей.
MLOps: если ближе работа с данными и ML
Если вы работаете с Python, данными и машинным обучением, обратите внимание на MLOps. Инженер этого направления выстраивает инфраструктуру для работы ML-моделей: автоматизирует обучение и развертывание, обеспечивает воспроизводимость экспериментов, мониторит качество моделей и дрейф данных.
Помимо Docker, Kubernetes и CI/CD, в MLOps используют MLflow, DVC и другие инструменты для управления жизненным циклом моделей.
По данным «Хабр Карьеры» на июнь 2026 года, медианная зарплата MLOps-специалистов среднего уровня — 256 тысяч рублей. Инженерам с большим опытом и экспертизой платят в среднем 417 тысяч рублей.
Как понять, что направление вам подходит
Лучший способ выбрать карьерный вектор — попробовать. В PRO-курсах Яндекс Практикума по DevOps и MLOps есть бесплатные вводные части. За несколько часов вы познакомитесь с типичными задачами, инструментами и логикой работы специалистов. Этого достаточно, чтобы понять, насколько вам интересно новое направление, прежде чем принимать решение об обучении.
ООО «Яндекс», ИНН: 7736207543
Показать полностью
1
Вкатываемся в ИТ – 2026. Часть 17. Мотивация и квалификация еще раз
Для ЛЛ: Отраслей в ИТ много, но далеко не в каждой будет карьерный рост.
В российском (и не только российском, но я пишу все же по-русски) еще недавно стаж и технические знания были негласно приравнены к квалификации.
Сейчас в комментариях начали снова появляться «советские» темы про «стаж на одном месте».
По всем этим пунктам стоит пройти подробнее.
Почему именно по ним? Потому что статей «пять лучших вопросов на жависта \ дба \ девопса\ эникея» написано множество. Лучшие из этих статей называются «экзамен от Pearson VUE», например RHCSA , GGLVCH-GCCPCDOE, CCNP, и так далее. Прочитал, выучил, сдал, вкатился.
В стаже на одном месте ничего плохого нет. Кроме тех двух фактов, что умеренно частая (раз в 2-4 года) смена работы ведет к росту зарплаты (статистически), и того, что на одной и той же работе могут потребоваться навыки, специфичные только для этой работы, и не требующиеся больше нигде. ЕСЛИ рынок на подъёме, и если есть оплачиваемый спрос на труд. Не разговоры про «не тех зумеров», а оплачиваемый спрос.
Раньше было иначе, напоминает Сапата. Если вы оставались лояльны компании, та заботилась о вас в течение всей вашей жизни. Теперь это уже не так. Постоянная работа на одном месте давно перестала приносить те выгоды, что были в 1980–1990-х: корпоративные пенсии обесценились, реальная зарплата не растет, и ее часто не хватает, чтобы оплачивать текущие счета, не говоря уже о покупке жилья; бонусы вроде бесплатной еды в офисе этого не компенсируют. К тому же 70% работников опасаются увольнения. В результате держаться становится просто не за что.
Текучка кадров может быть для компаний еще опаснее, чем кажется на первый взгляд. Как отмечает французский экономист Тома Пикетти в книге «Капитал в XXI веке», от сотрудников часто требуется развивать особые навыки, которые потребуются только в этой компании. Это так называемые специфические инвестиции, и их в компанию делают работники. «Например, речь может идти о методах работы, особенностях организации или особых навыках, связанных со специфическим производственным процессом на данном предприятии», — поясняет экономист.
https://www.rbc.ru/education/02/02/2026/69686ff39a7947ad933e...
Но есть интересное наблюдение. Как только персонаж начинает хвастаться «да я NNN лет на одном месте, что вы понимаете в локальном бизнесе, сосунки», то, вполне возможно, он занимался именно локальными задачами бизнеса. Например, работал в местном коровнике и крутил хвосты коровам, а пришедшие на замену автоматизированные доильные станки называет новомодными выдумками, которые не нужны, не окупятся, и прочее не.
В комментариях к прошлому посту был один такой, «да я девопс, я нейросеть за километр вижу». Иронично, но эта серия, вся, написана вручную, и не доводилась на креативном доводчике.
В остальном персонаж был бы хорошим примером – ни одной статьи про ИТ, ни одного комментария по теме, ничего. Но, якобы девопс. Это не проверяемо, да и нужно ли это проверять?
В жизни с такими «экспертами в себе», которые считают, что знают «как делать», но не знают «почему», придется сталкиваться постоянно. Зато у них стаж, субординация и выслуга лет. И генерала могут за погон укусить.
С техническими знаниями ситуация еще сложнее, и с этим вновь вкатывающимся придется сталкиваться все чаще.
В РФ идет театрализованное представление «Про СССР, но с перламутровыми пуговицами». Я бы сказал «косплей на минималках», потому что СССР был, все же, сверхдержавой, перепрыгнувшей с второго технологического уклада на третий, и попытавшейся перепрыгнуть в четвертый. Сейчас, если кто-то не в курсе, идет переход с пятого на шестой уклад.
Из примерно этого, «позднего советского времени", уже застоя, рисуется картина «знающий технику равно задрот не на спорте». В лице Александра Привалова, нарисованного с Шурика, сидящего на сгоревшем устройстве Алдана с 1964 года. Про его судьбу в начале 1990-х некто Харитонов написал лживый пасквиль, который я не читал, как и Пастернака, но осуждаю. В списке литературы есть обе.
Почему HR пытаются продать бизнесу историю, что где-то в темном углу какой-то Вася тридцать лет и три года ждет, когда HR его найдет и выведет в свет – понятно. Потому что есть мечта о беспонтовом пирожке без амбиций, работающем 12/6 за плошку риса.
Почему бизнес покупает такие истории, тоже понятно. Потому что иначе придется уволить весь HR отдел за профнепригодность. Этого делать нельзя, они «чьи-то».
Как же хорошо, что я уже три года не занимаюсь наймом и первичными интервью. Хотя, ничего против того, чтобы иметь подругу из HR, я не имею. Как там пел забытый певец, когда это еще было можно - И обе они мне подруги, и обе упруги.
Реальность, как всегда, далека от моего понимания.
По моему мнению, общая квалификация сейчас это не одно число, точнее не один вектор, и не может быть сведена к единичному вектору.
Это минимум три параметра:
- Академические знания, в том числе умение их применять на реальных объектах. И применять корректно.
- Мотивация к их правильному и постоянному применению, и улучшению знаний. Хотя бы из лени.
Я уже не один и не два раза видел кандидатов, которые вроде знают «как надо», но каждый раз делают «как проще, на соплях». Причем, это никак не зависит от возраста, я видел и дедов 55+, которые делали и защищали как «работает же» удивительное говнище, на скрутках под изолентой вместо пружинных клемников, и вчерашних школьников 18 лет, которые читали и учились «на ходу» - с ростом зарплаты до «х3 от дедов», кстати. За год-два.
- Социализация в форме, достаточной для работы в команде, с делегированием задач «вниз, вверх и вбок», с пониманием, что есть цели, которые достигать нужно, и которые не очень нужно достигать, хотя генеральный директор сказал, что «план – закон, выполнение – долг, перевыполнение – честь». План по прибыли в частной организации с неоплачиваемыми переработками, причем такой, что его и с переработками не выполнить.
Заключение
Вкатиться в базовый уровень ИТ в Москве легко даже сейчас. Тык, тык, готов эникей.
Выше идти сложно.
Литература
Время летунов. Почему частая смена работы стала выигрышной стратегией
https://www.rbc.ru/education/02/02/2026/69686ff39a7947ad933e5253
Карьерный эксперт развеяла миф о том, как часто стоит менять работу
https://dszn.ru/press-center/news/13652
Серия «Унылое графоманство номер шесть»
Харитонов, Рубидий
Читать эти 6 книг нужно именно в таком порядке, по мере выхода книг.
Остальные читать в любом порядке.
1 Фредерик Уинслоу Тейлор . Принципы научного менеджмента
Удивительно, но по запросу «тейлор научная организация труда читать онлайн» книга будет не второй ссылкой, а четвертой.
2 «Мифический человеко-месяц, или Как создаются программные системы» (англ. The Mythical Man-Month: Essays on Software Engineering)
3 Deadline. Роман об управлении проектами
4 Проект Феникс. Роман о том как DEVOPS меняет бизнес к лучшему
5 Весь цикл «Рождение советской ПРО»: https://topwar.ru/user/Sperry/
Можно читать даже комментарии, где пишут, что автор ничего не понимает, либерал и вредитель.
Но, среди членов клуба зануд он считается опасным интеллектуалом.
6 Билл Гейтс. Бизнес со скоростью мысли
Для тех, кто до сюда дочитал.
Вопросы "не раскрыта тема .." в комментариях задавать можно и нужно.
Писать "мне не понравилось, экшену маловато" - тоже.
При написании этого текста было потрачено ноль токенов.
Это ужасно. Уже раннее утро, а я в носу ковыряюсь
Показать полностью
1
1
