Но это говорит не о том что каждое фото в инсте - шедевр. А о том, что большинство людей устраивает как снимает их смартфон. Не важно, что оно с художественной точки зрения - "ни о чем", потому что с технической стороны щас техника в основном не дает шансов налажать пользователю. А вот тем, кто ценит именно художественную составляющую, которые хотят чтобы на фото взгляд задерживался, чтобы его рассматривали, чтобы там была жизнь и эмоции - они идут к профи и платят деньги. Да, их немного (как заказчиков, так и профи) - но они есть.
Я в свое время проходил через все эти этапы - отдельные виртуалки под каждый проект со своим впн внутри, настройка всех впн на роутере и маршрутизация в зависимости от сети, поднятие отдельного впн на VPS до нужных проектов и настройка маршрутов на нем, а из домашней сети - подключение только до него. Но последние 2 работы сменил парадигму - на работе выдают ноут с подключением к корпоративной сети, я на нем и работаю. Все! ) Купил логитечевскую клаву k375s и мышь триатлон, настроил подключение к одному рабочему ноуту и двум своим домашним компам - один под линуксом, другой под виндой (основной Линукс, но винда периодически нужна тоже). На рабочем ноуте работу работаю, на домашних - свои задачи решаю. Да, это 3 разных устройства, но зато четкое разделение - на рабочем компе нет ничего из личных файлов, только рабочая история. На личных компах - свои проекты, без заморочек с доступом к корпсети и проблем из-за впн.
Отчасти согласен с автором, что наличие незаменимого специалиста в команде несет риски для команды. Но хотелось бы описать ситуацию и с другой стороны, со стороны такого незаменимого специалиста. Я на одном из этапов своей карьеры был тем самым незаменимым специалистом и вот какие отрицательные моменты для меня это несло: 1) В рабочее время ты в основном решаешь чьи-то проблемы, объясняешь, почему это не работает, или работает не так, поскольку кроме тебя это никто не знает - и почти совсем не решаешь свои рабочие вопросы или же решаешь их в послерабочее время 2) Почти нет свободного времени - в выходные и вечером тебе могут позвонить потому что что-то где-то упало и надо либо срочно выезжать либо чинить по удаленке. Я почти 3 года не мог сходить в отпуск нормально по этой причине - максимум на неделю и чтобы был всегда на связи. 3) Я был бы рад поделиться знаниями, но на тот момент либо никого не было, кому эти знания передать, либо не было времени, чтобы это все хорошо задокументировать - хорошо, что на память я в то время не жаловался. В определенный момент меня это все достало и я пошел к руководству и сказал, что я не вывожу это в одного и мне нужен помощник. Помощник появился через какое-то время и я, введя его в общий курс дел и поделившись с ним теми самыми недоступными никому знаниями, отправил его в свободное плавание, делегировав ему часть своих задач. Первое время он обращался ко мне несколько раз в день, но со временем кол-во обращений снизилось до 1-2 в неделю. Ситуация через какое-то время повторилась со вторым сотрудником, у нас наконец-то появилась возможность это все задокументировать хоть как-то и еще через год после всего этого я смог наконец-то уехать в отпуск на 2 недели и никто не звонил мне во время отпуска. И когда я через несколько лет уволился, то я четко знал, что все что я знал - оно не осталось только у меня, есть люди, которые смогут справиться с теми задачами, которые решал я, когда был незаменимым.
Когда-то давным давно, ещё в Технике Молодёжи (ЕМНИП) была очень хорошая статья с картинками о средствах спасения на советских ракетах. Так вот, там писалось, что спасение космонавтов возможно фактически на любом из этапов старта - даже когда ракета стоит на столе, но ещё не взлетела, а спасать космонавтов надо. Учитывая что все наши ракеты ещё оттуда - я думаю тут ничего не изменилось
Если проектируешь модель сам, то ты можешь: 1) спроектировать ее с учетом будущей печати так, чтобы будущая нагрузка и слои при печати располагались наиболее оптимальным образом. 2) в высоконагруженных местах, где высок риск разрушения модели, можно применять не столько утолщения - я обычно ими никогда и не пользуюсь - а сколько ребра жесткости, на отверстиях сквозных я стараюсь делать дополнительные цилиндрические, выступающие над корпусом на несколько миллиметров, утолщения радиусом на 20% больше основного отверстия - это положительно сказывается на прочности самих отверстий 3) Заполнение 70-80% и выбор пластика под задачу - сейчас есть куча принтеров, которые могут печатать высокотемпературными пластиками И для своих домашних задач этого вполне оказывается достаточно.
А почему не рассматривается вариант с динамическим inventory, когда мы хосты описываем один раз, но с разными лейблами, а затем на основе лейблов формируем разные группы, в зависимости от того, какие лейблы какое значение имеют? Потому что иначе одни и те же хосты в статических инвентори будут находиться в разных файлах и если вдруг у него сменится адрес, то надо идти и править это все во всех инвентори, где он был указан. Или же если у него добавится новая роль - то надо идти и добавлять в нужном файле/группе этот сервер.
Вставлю свои 5 копеек, поскольку тоже реализовывал в свое время свою утилиту по процессам ), правда не аналог top, а скорее аналог ps, ну и не на С, а на go. Итак, что меня не устраивало в текущих утилитах типа ps/top и что мне часто нужно было видеть по работе - возможно вам это тоже будет полезно: 1) Нужно было видеть, сколько и какой процесс потребляет свопа, потому что часто с ним возникала проблема. 2) Нужно было понимание, процесс запущен на хосте или же в контейнере - во всех утилитах для этого приходится делать дополнительные действия, чтобы выяснить это. 3) Нужна фильтрация - показать только процессы, запущенные в контейнерах, показать процессы у которых потребление какого-то одного или нескольких ресурсов (например cpu и памяти или cpu и swap) больше определенных значений 4) желательно чтобы вывод команды можно было настраивать и чтобы этот вывод потом можно было бы использовать в пайпах для других программ
На мой взгляд это просто очередной этап эволюции "компьютерщика". Когда появились первые ПК, тогда не было айтишников, тогда были компьютерщики, которые и в железе разбирались и программы какие-то писали. Потом пошло разделение на тех, кто занимается аппаратной частью и программной. Появились программисты) потом выяснилось, что программисты разные нужны, есть прикладные, системные, веб(фронт, бэк) и т.д.
Админы тоже начали разделяться как с программистами - есть сетевые, инфраструктурные, DBA - потому что все усложняется и в рамках одной роли/одного человека уже не получается это все нормально вывозить. Поэтому выделение отдельных ролей для DevOPs инженеров и SRE - это вполне нормальный процесс. И то что один человек это когда то делал или делает сейчас - это тоже нормально, просто на тот момент требования/сложности процесса обслуживания приложения в проде были другие.
Тут аналогия как с врачами - в начале 20 века врач и от простуды лечил и операции делал. А сейчас это совсем разные специальности, даже у хирургов есть свои специализации. Просто в ИТ это идет немного быстрее, чем в медицине.
Тогда мне не совсем понятно, где вам надо прописывать и читать адреса, если у вас используется DNS? Можете привести какой-то пример, где необходимо использование именно IP адресов, а не имен хостов? И для чего/кого вы экономите эти 3-4 цифры в адресе? На мой взгляд, использование адресов в графиках и таблицах очень часто может приводить к трудно отслеживаемым ситуациям когда человеческий глаз замыливается и можно не увидеть разницы между двумя похожими адресами.
То есть, если я правильно понял вашу мысль, вы все адреса прописываете всегда руками и поэтому 192.168.х.х для вас - это долго набирать, как и 172.16.х.х, а вот 10.х.х.х - явно меньше и короче и других причин для этого нет?
"то глазами системного администратора увидите много замечательных вещей: начиная от использования адресов 192.168.X.X вместо 10.X.X.X " А вот тут мне непонятно, почему нельзя использовать сеть 192.168.0.0/16, а сразу фигачить на 10.0.0.0/8? А как же промежуточный вариант с 172.16.0.0/12? Обычно при выборе сетевых адресов и масок отталкиваются от кол-ва сетевых устройств и связности между разными сегментами, вполне может быть ситуация, когда используют все 3 зарезервированные сети - правда это обычно телеком операторы крупные.
Интересно, почему не стали использовать типичный сценарий, когда трафик с роутера снимается через netflow и потом обрабатывается коллекторами? Как вариант - связка ELK для хранения, сбора/обработки и отображения.
А можно ли Станцию 2 интегрировать с HomeAssistant? Чтобы, к примеру, управлять Zigbeee устройствами что к нему подключены ну или хотя бы плейлистом? Планируется ли какое-то API для этого?
Если мне память не изменяет, то сама Икея так позиционирует свои лампы — с матовым стеклом — это те, которые размещены открыто или в прозрачном светильнике. С прозрачным стеклом — для установки в матовые светильники.
Вообще-то ТО делается как по пробегу, так и по времени — в зависимости от того, какое граничное условие наступило первым. Например, масло в АКПП надо менять либо через 40 000 км, либо через 4 года. Масло в двигателе надо менять либо раз в 10 000 км, либо раз в год. И т. д. И с покрышками такая же история — буквально в этом году пришлось менять резину, по протектору она могла бы отъездить еще пару сезонов, но из-за того, что у всего есть срок эксплуатации, на 2х покрышках появились микротрещины и они теряли по 0.8 атм за 2 недели.
Но это говорит не о том что каждое фото в инсте - шедевр. А о том, что большинство людей устраивает как снимает их смартфон. Не важно, что оно с художественной точки зрения - "ни о чем", потому что с технической стороны щас техника в основном не дает шансов налажать пользователю.
А вот тем, кто ценит именно художественную составляющую, которые хотят чтобы на фото взгляд задерживался, чтобы его рассматривали, чтобы там была жизнь и эмоции - они идут к профи и платят деньги. Да, их немного (как заказчиков, так и профи) - но они есть.
Я в свое время проходил через все эти этапы - отдельные виртуалки под каждый проект со своим впн внутри, настройка всех впн на роутере и маршрутизация в зависимости от сети, поднятие отдельного впн на VPS до нужных проектов и настройка маршрутов на нем, а из домашней сети - подключение только до него.
Но последние 2 работы сменил парадигму - на работе выдают ноут с подключением к корпоративной сети, я на нем и работаю. Все! )
Купил логитечевскую клаву k375s и мышь триатлон, настроил подключение к одному рабочему ноуту и двум своим домашним компам - один под линуксом, другой под виндой (основной Линукс, но винда периодически нужна тоже).
На рабочем ноуте работу работаю, на домашних - свои задачи решаю. Да, это 3 разных устройства, но зато четкое разделение - на рабочем компе нет ничего из личных файлов, только рабочая история. На личных компах - свои проекты, без заморочек с доступом к корпсети и проблем из-за впн.
Отчасти согласен с автором, что наличие незаменимого специалиста в команде несет риски для команды. Но хотелось бы описать ситуацию и с другой стороны, со стороны такого незаменимого специалиста.
Я на одном из этапов своей карьеры был тем самым незаменимым специалистом и вот какие отрицательные моменты для меня это несло:
1) В рабочее время ты в основном решаешь чьи-то проблемы, объясняешь, почему это не работает, или работает не так, поскольку кроме тебя это никто не знает - и почти совсем не решаешь свои рабочие вопросы или же решаешь их в послерабочее время
2) Почти нет свободного времени - в выходные и вечером тебе могут позвонить потому что что-то где-то упало и надо либо срочно выезжать либо чинить по удаленке. Я почти 3 года не мог сходить в отпуск нормально по этой причине - максимум на неделю и чтобы был всегда на связи.
3) Я был бы рад поделиться знаниями, но на тот момент либо никого не было, кому эти знания передать, либо не было времени, чтобы это все хорошо задокументировать - хорошо, что на память я в то время не жаловался.
В определенный момент меня это все достало и я пошел к руководству и сказал, что я не вывожу это в одного и мне нужен помощник. Помощник появился через какое-то время и я, введя его в общий курс дел и поделившись с ним теми самыми недоступными никому знаниями, отправил его в свободное плавание, делегировав ему часть своих задач. Первое время он обращался ко мне несколько раз в день, но со временем кол-во обращений снизилось до 1-2 в неделю. Ситуация через какое-то время повторилась со вторым сотрудником, у нас наконец-то появилась возможность это все задокументировать хоть как-то и еще через год после всего этого я смог наконец-то уехать в отпуск на 2 недели и никто не звонил мне во время отпуска. И когда я через несколько лет уволился, то я четко знал, что все что я знал - оно не осталось только у меня, есть люди, которые смогут справиться с теми задачами, которые решал я, когда был незаменимым.
Когда-то давным давно, ещё в Технике Молодёжи (ЕМНИП) была очень хорошая статья с картинками о средствах спасения на советских ракетах. Так вот, там писалось, что спасение космонавтов возможно фактически на любом из этапов старта - даже когда ракета стоит на столе, но ещё не взлетела, а спасать космонавтов надо. Учитывая что все наши ракеты ещё оттуда - я думаю тут ничего не изменилось
Если проектируешь модель сам, то ты можешь:
1) спроектировать ее с учетом будущей печати так, чтобы будущая нагрузка и слои при печати располагались наиболее оптимальным образом.
2) в высоконагруженных местах, где высок риск разрушения модели, можно применять не столько утолщения - я обычно ими никогда и не пользуюсь - а сколько ребра жесткости, на отверстиях сквозных я стараюсь делать дополнительные цилиндрические, выступающие над корпусом на несколько миллиметров, утолщения радиусом на 20% больше основного отверстия - это положительно сказывается на прочности самих отверстий
3) Заполнение 70-80% и выбор пластика под задачу - сейчас есть куча принтеров, которые могут печатать высокотемпературными пластиками
И для своих домашних задач этого вполне оказывается достаточно.
А почему не рассматривается вариант с динамическим inventory, когда мы хосты описываем один раз, но с разными лейблами, а затем на основе лейблов формируем разные группы, в зависимости от того, какие лейблы какое значение имеют?
Потому что иначе одни и те же хосты в статических инвентори будут находиться в разных файлах и если вдруг у него сменится адрес, то надо идти и править это все во всех инвентори, где он был указан. Или же если у него добавится новая роль - то надо идти и добавлять в нужном файле/группе этот сервер.
Вставлю свои 5 копеек, поскольку тоже реализовывал в свое время свою утилиту по процессам ), правда не аналог top, а скорее аналог ps, ну и не на С, а на go.
Итак, что меня не устраивало в текущих утилитах типа ps/top и что мне часто нужно было видеть по работе - возможно вам это тоже будет полезно:
1) Нужно было видеть, сколько и какой процесс потребляет свопа, потому что часто с ним возникала проблема.
2) Нужно было понимание, процесс запущен на хосте или же в контейнере - во всех утилитах для этого приходится делать дополнительные действия, чтобы выяснить это.
3) Нужна фильтрация - показать только процессы, запущенные в контейнерах, показать процессы у которых потребление какого-то одного или нескольких ресурсов (например cpu и памяти или cpu и swap) больше определенных значений
4) желательно чтобы вывод команды можно было настраивать и чтобы этот вывод потом можно было бы использовать в пайпах для других программ
На мой взгляд это просто очередной этап эволюции "компьютерщика". Когда появились первые ПК, тогда не было айтишников, тогда были компьютерщики, которые и в железе разбирались и программы какие-то писали. Потом пошло разделение на тех, кто занимается аппаратной частью и программной. Появились программисты) потом выяснилось, что программисты разные нужны, есть прикладные, системные, веб(фронт, бэк) и т.д.
Админы тоже начали разделяться как с программистами - есть сетевые, инфраструктурные, DBA - потому что все усложняется и в рамках одной роли/одного человека уже не получается это все нормально вывозить. Поэтому выделение отдельных ролей для DevOPs инженеров и SRE - это вполне нормальный процесс. И то что один человек это когда то делал или делает сейчас - это тоже нормально, просто на тот момент требования/сложности процесса обслуживания приложения в проде были другие.
Тут аналогия как с врачами - в начале 20 века врач и от простуды лечил и операции делал. А сейчас это совсем разные специальности, даже у хирургов есть свои специализации. Просто в ИТ это идет немного быстрее, чем в медицине.
Тогда мне не совсем понятно, где вам надо прописывать и читать адреса, если у вас используется DNS? Можете привести какой-то пример, где необходимо использование именно IP адресов, а не имен хостов? И для чего/кого вы экономите эти 3-4 цифры в адресе? На мой взгляд, использование адресов в графиках и таблицах очень часто может приводить к трудно отслеживаемым ситуациям когда человеческий глаз замыливается и можно не увидеть разницы между двумя похожими адресами.
То есть, если я правильно понял вашу мысль, вы все адреса прописываете всегда руками и поэтому 192.168.х.х для вас - это долго набирать, как и 172.16.х.х, а вот 10.х.х.х - явно меньше и короче и других причин для этого нет?
"то глазами системного администратора увидите много замечательных вещей: начиная от использования адресов 192.168.X.X вместо 10.X.X.X "
А вот тут мне непонятно, почему нельзя использовать сеть 192.168.0.0/16, а сразу фигачить на 10.0.0.0/8? А как же промежуточный вариант с 172.16.0.0/12? Обычно при выборе сетевых адресов и масок отталкиваются от кол-ва сетевых устройств и связности между разными сегментами, вполне может быть ситуация, когда используют все 3 зарезервированные сети - правда это обычно телеком операторы крупные.
Нет, для протяжки необходимо чтобы отверстие уже было, а она его доводит до необходимой точности, а вот сверло как раз таки формирует отверстие
Интересно, почему не стали использовать типичный сценарий, когда трафик с роутера снимается через netflow и потом обрабатывается коллекторами? Как вариант - связка ELK для хранения, сбора/обработки и отображения.
А как же Бригада Е5 и ее продолжение 7.62 ? Неплохие тактические игры для своего времени
А можно ли Станцию 2 интегрировать с HomeAssistant? Чтобы, к примеру, управлять Zigbeee устройствами что к нему подключены ну или хотя бы плейлистом? Планируется ли какое-то API для этого?
Есть же - от большого слова data правее последней а, третье слово в верхнем ряду
Если мне память не изменяет, то сама Икея так позиционирует свои лампы — с матовым стеклом — это те, которые размещены открыто или в прозрачном светильнике. С прозрачным стеклом — для установки в матовые светильники.