Как устроен и работает брандмауэр Windows
Брандмауэр Windows впервые был представлен в 2001 году вместе с выходом SP2 для Windows XP, а современный облик приобрел вместе с выходом Windows Vista, но не смотря на столь преклонный возраст для многих он до сих пор остается чем-то непонятным.
Такую ситуацию нельзя считать нормальной, как и полное отключение брандмауэра. Поэтому сегодня мы рассмотрим, как устроен и работает брандмауэр Windows, как он взаимодействует с пользователем и как следует составлять и читать его правила.
Мы уже не раз и не два говорили, что Microsoft имеет талант давать своим продуктам неудачные названия, которые очень часто становятся еще хуже при переводе на другие языки. Так и в этом случае, основной рабочий интерфейс брандмауэра называется Монитор брандмауэра Защитника Windows в режиме повышенной безопасности.
Длинно, мудрено и еще повышенную безопасность зачем-то приплели, но другого графического интерфейса для управления брандмауэром в Windows нет. Попасть в него можно классическим путем через Панель управления - Брандмауэр Защитника Windows - Дополнительные параметры.
Туда же туда ведут несколько разных путей, например, через свойства сетевых подключений, но в разных версиях Windows эти пути могут быть различны и нами не рассматриваются.
✅ Читать далее: https://interface31.ru/post/kak-ustroen-i-rabotaet-brandmauer-windows/
Брандмауэр Windows впервые был представлен в 2001 году вместе с выходом SP2 для Windows XP, а современный облик приобрел вместе с выходом Windows Vista, но не смотря на столь преклонный возраст для многих он до сих пор остается чем-то непонятным.
Такую ситуацию нельзя считать нормальной, как и полное отключение брандмауэра. Поэтому сегодня мы рассмотрим, как устроен и работает брандмауэр Windows, как он взаимодействует с пользователем и как следует составлять и читать его правила.
Мы уже не раз и не два говорили, что Microsoft имеет талант давать своим продуктам неудачные названия, которые очень часто становятся еще хуже при переводе на другие языки. Так и в этом случае, основной рабочий интерфейс брандмауэра называется Монитор брандмауэра Защитника Windows в режиме повышенной безопасности.
Длинно, мудрено и еще повышенную безопасность зачем-то приплели, но другого графического интерфейса для управления брандмауэром в Windows нет. Попасть в него можно классическим путем через Панель управления - Брандмауэр Защитника Windows - Дополнительные параметры.
Туда же туда ведут несколько разных путей, например, через свойства сетевых подключений, но в разных версиях Windows эти пути могут быть различны и нами не рассматриваются.
✅ Читать далее: https://interface31.ru/post/kak-ustroen-i-rabotaet-brandmauer-windows/
👍16❤1🤮1
Ток, напряжение, мощность
Как показывают обсуждения, не все читатели, а особенно читательницы, понимают основы электротехники и делают неправильные выводы, хотя это истины доступны любому студенту электротехнического колледжа.
Поэтому с них и начнем, постаравшись объяснить наиболее простым языком, в максимально упрощенном виде. Начнем с терминов и аналогий:
🔹 Напряжение – это разность потенциалов, которую можно представить как перепад высот, с которых у нас потечет вода (ток), чем больше этот перепад, тем сильнее потечет вода (больше будет ток).
🔹 Ток – поток заряженных частиц, выполняющих полезную (или бесполезную работу), в нашей аналогии та самая вода.
🔹 Мощность – та самая проделанная работа, которую выполнил поток воды (электрический ток).
Классическая формула мощности:
Как видим, формула линейно зависит как от напряжения, так и от тока. Теоретически мы можем играть от обеих сторон, но это чисто теоретически.
Вернемся к нашей аналогии, давайте возьмем мощность в 1200 Вт, для 12 В это будет ток в 100 А, а для 400 В всего в 3 А. Ну и что? А снова вернемся к воде, для выполнения одной и той же работы нам нужно или 3 куба воды или 100 кубов. Есть разница?
А что будет, если у нас что-то пойдет не так, и эта вода неконтролируемо растечется? Ну три куба спокойно по канавке стекут в ближайшую реку, а вот 100 кубов способны наделать бед.
И вода веде не просто течет на условную мельницу, кроме полезной работы она делает и совсем не полезную – подмывает берега, переносит грунт. Так и ток, протекая через проводники он их нагревает, потому как проводники обладают некоторым сопротивлением, приводящим к потерям.
А так как работу выполняет именно ток, то мощность, выделяемая на сопротивлении (а любой проводник – это сопротивление) рассчитывается по формуле:
В нашем случае результат будет отличаться на порядки, хотя полезная мощность нагрузки не изменится.
Так при сопротивлении проводника в 1 Ом и полезной нагрузке 1200 Вт при 400 В и 3 А потери в проводнике составят всего 9 Вт, не мало, но и не много, обычный пассивный радиатор проблему решит.
А вот при 12 В и 100 А на этом же проводнике в виде тепла выделится 10 кВт, которые нам нужно или куда-то деть (отопить помещение) или у нас начнет гореть и плавиться сам проводник, плата под ним, соседние детали, корпус.
Хотя на самом деле такого тока в этой цепи возникнуть не может и больше 12 А там не потечет. Закон Ома, но и 144 Вт – это уже не шутки, без активного охлаждения не обойтись.
Поэтому нормальный путь – это повышение напряжения, грубо говоря повысив напряжение в 2 раза и на столько же уменьшив ток, при одной и той же мощности нагрузки, мы уменьшаем потери в 4 раза. Именно поэтому магистральные ЛЭП сплошь высоковольтные.
Но бесконечно увеличивать напряжение мы не можем, ток, он как вода, ищет любую дырочку. И при определенной разности потенциалов он может заставить электроны начать упорядоченное движение даже в непроводящей среде.
Для бытовой техники с допусками по влажности и наличии в воздухе пыли принято считать, что 1 см воздуха пробивается 1 кВ напряжения. А это создает ненужные риски.
Поэтому импульсные блоки питания работают на уровне примерно 400 В – золотой середине, потери падают квадратично и можно отлично экономить на сечении проводов, размере компонентов и теплоотводов, но не подвергая себя риску электрического пробоя.
А все высокотоковые цепи стараются разместить как можно ближе к потребителю, не даром на материнской плате VRM прижат как можно ближе к сокету. Потому что мизерные напряжения питания процессора обуславливают крайне высокие токи.
Повысить напряжение мы не можем, так как уменьшение технологического процесса требует понижения напряжения, во избежание электрического пробоя.
Меньше напряжение – больше ток и квадратично большее тепловыделение, которое и стало главным ограничивающим фактором роста частот и быстродействия современной электроники.
Как показывают обсуждения, не все читатели, а особенно читательницы, понимают основы электротехники и делают неправильные выводы, хотя это истины доступны любому студенту электротехнического колледжа.
Поэтому с них и начнем, постаравшись объяснить наиболее простым языком, в максимально упрощенном виде. Начнем с терминов и аналогий:
🔹 Напряжение – это разность потенциалов, которую можно представить как перепад высот, с которых у нас потечет вода (ток), чем больше этот перепад, тем сильнее потечет вода (больше будет ток).
🔹 Ток – поток заряженных частиц, выполняющих полезную (или бесполезную работу), в нашей аналогии та самая вода.
🔹 Мощность – та самая проделанная работа, которую выполнил поток воды (электрический ток).
Классическая формула мощности:
P = I *U
Как видим, формула линейно зависит как от напряжения, так и от тока. Теоретически мы можем играть от обеих сторон, но это чисто теоретически.
Вернемся к нашей аналогии, давайте возьмем мощность в 1200 Вт, для 12 В это будет ток в 100 А, а для 400 В всего в 3 А. Ну и что? А снова вернемся к воде, для выполнения одной и той же работы нам нужно или 3 куба воды или 100 кубов. Есть разница?
А что будет, если у нас что-то пойдет не так, и эта вода неконтролируемо растечется? Ну три куба спокойно по канавке стекут в ближайшую реку, а вот 100 кубов способны наделать бед.
И вода веде не просто течет на условную мельницу, кроме полезной работы она делает и совсем не полезную – подмывает берега, переносит грунт. Так и ток, протекая через проводники он их нагревает, потому как проводники обладают некоторым сопротивлением, приводящим к потерям.
А так как работу выполняет именно ток, то мощность, выделяемая на сопротивлении (а любой проводник – это сопротивление) рассчитывается по формуле:
P = I^2 * R
В нашем случае результат будет отличаться на порядки, хотя полезная мощность нагрузки не изменится.
Так при сопротивлении проводника в 1 Ом и полезной нагрузке 1200 Вт при 400 В и 3 А потери в проводнике составят всего 9 Вт, не мало, но и не много, обычный пассивный радиатор проблему решит.
А вот при 12 В и 100 А на этом же проводнике в виде тепла выделится 10 кВт, которые нам нужно или куда-то деть (отопить помещение) или у нас начнет гореть и плавиться сам проводник, плата под ним, соседние детали, корпус.
Хотя на самом деле такого тока в этой цепи возникнуть не может и больше 12 А там не потечет. Закон Ома, но и 144 Вт – это уже не шутки, без активного охлаждения не обойтись.
Поэтому нормальный путь – это повышение напряжения, грубо говоря повысив напряжение в 2 раза и на столько же уменьшив ток, при одной и той же мощности нагрузки, мы уменьшаем потери в 4 раза. Именно поэтому магистральные ЛЭП сплошь высоковольтные.
Но бесконечно увеличивать напряжение мы не можем, ток, он как вода, ищет любую дырочку. И при определенной разности потенциалов он может заставить электроны начать упорядоченное движение даже в непроводящей среде.
Для бытовой техники с допусками по влажности и наличии в воздухе пыли принято считать, что 1 см воздуха пробивается 1 кВ напряжения. А это создает ненужные риски.
Поэтому импульсные блоки питания работают на уровне примерно 400 В – золотой середине, потери падают квадратично и можно отлично экономить на сечении проводов, размере компонентов и теплоотводов, но не подвергая себя риску электрического пробоя.
А все высокотоковые цепи стараются разместить как можно ближе к потребителю, не даром на материнской плате VRM прижат как можно ближе к сокету. Потому что мизерные напряжения питания процессора обуславливают крайне высокие токи.
Повысить напряжение мы не можем, так как уменьшение технологического процесса требует понижения напряжения, во избежание электрического пробоя.
Меньше напряжение – больше ток и квадратично большее тепловыделение, которое и стало главным ограничивающим фактором роста частот и быстродействия современной электроники.
1👍30❤8🤔3🤡2🔥1
У Васи есть папка с закачками, куда он скачивает без разбора всякое разное, и чтобы каждый раз не разбирать ее руками он пишет скрипт, который будет автоматически перемещать видеоролики в другую папку:
Что не так с этим скриптом?
👇 Ответы в опросе ниже 👇
for file in $(ls *.mp4); do
mv -f $file /new_path/video
done
Что не так с этим скриптом?
👇 Ответы в опросе ниже 👇
👌2❤1🤡1
Что не так со скриптом Васи?
Предположений было довольно много, но большинство указанных и неуказанных в опросе, но всплывшие в обсуждении недостатки не являются фатальными.
Основной и очень грубой ошибкой является использование для получения списка файлов команды ls, также все сказанное далее в полной мере относится и к find. Обе эти команды созданы для интерактивного взаимодействия с оператором и не предназначены для использования в скриптах.
Почему? В обсуждении было приведено несколько хороших ссылок на подробные материалы, правда на английском, но даже с переводчиком смысл будет понятен. Мы же остановимся коротко на основных проблемах.
🔹 Первая и самая очевидная - пробелы, имя файла с пробелами превратится в набор строк, каждая из которых будет обрабатываться скриптом отдельно. И если в данном примере это относительно безопасно, то в реальных сценариях это может привести к абсолютно непредсказуемым последствиям.
Например, в нашей практике мы сталкивались со скриптом, который таким образом подсчитывал количество файлов в папке, потом сортировал их по дате создания и удалял самые старые, чтобы осталось всего N-файлов. Файл с пробелами в имени сразу грубо ломает эту логику и может привести к удалению нужных данных.
Обернуть ls *.mp4 в кавычки тоже не даст результата, так как в этом случае в качестве единой строки будет использоваться весь вывод команды.
🔹Вторая проблема – возможное наличие в имени файла управляющих и подстановочных символов. На практике встречается гораздо реже, но так как Linux вполне допускает подобные имена, то вы вполне можете с ними столкнуться, например, они могут появиться в результате ошибок в работе скриптов.
Допустим у вас есть набор файлов: 1Сезон-1Серия.mp4, 1Сезон-2Серия.mp4 и т.д. и туда случайным образом затесался файл где имя состоит из единицы и звездочки за ним. Символ звездочки будет расценен как подстановочный и ls подставит туда все попадающие под маску файлы. В результате все ваши серии попадут в вывод два раза. Как мы уже говорили, если в данном случае это безопасно, то в других сценариях может привести к различным негативным эффектам.
🔹Третья основная проблема – символы национальных алфавитов. Сейчас эта проблема отошла на второй план, но актуальной быть от этого не перестала. А причина все таже – ls и find рассчитаны на то, чтобы выводить информацию на экран.
А далее все зависит от установленной локали, если локаль не содержит символа, соответствующего его коду, то на его месте появится «крякозябкрик» или знак вопроса в ромбе, иди еще что-нибудь, а также такой символ может быть просто пропущен.
👆 Теперь о том, как сделать правильно. В оболочках POSIX, которым относится bash и его производные, есть функция позволяющая использовать в именах файлов символы подстановки, поэтому вывод никаких дополнительных команд анализировать не нужно, а переменную следует обязательно обернуть в кавычки:
В этом случае корректно будут отработаны и пробелы, и спецсимволы, и символы национальных алфавитов.
Также можно подстраховаться и добавить проверку на существование файла:
Если указанный файл не существует, то цикл пропустит текущую итерацию и перейдет к следующей.
👉 P.S. Почему мы заострили внимание именно на этой проблеме, а не на проверке наличия папки и наличия закрывающего слеша?
Потому что ls/find архитектурный баг скрипта, а остальное – частный случай с неправильной конфигурацией окружения.
Если Вася проследит, чтобы папка на момент запуска скрипта существовала – проблем у него не возникнет, никогда и никаких.
А вот использование ls/find для поиска файлов - это 100% проблема, заложенная архитектурно.
Если же Вася отразит в документации, мол перед запуском скрипта обязательно проверьте наличие целевой папки, то это уже будет не баг, а фича.
Предположений было довольно много, но большинство указанных и неуказанных в опросе, но всплывшие в обсуждении недостатки не являются фатальными.
Основной и очень грубой ошибкой является использование для получения списка файлов команды ls, также все сказанное далее в полной мере относится и к find. Обе эти команды созданы для интерактивного взаимодействия с оператором и не предназначены для использования в скриптах.
Почему? В обсуждении было приведено несколько хороших ссылок на подробные материалы, правда на английском, но даже с переводчиком смысл будет понятен. Мы же остановимся коротко на основных проблемах.
🔹 Первая и самая очевидная - пробелы, имя файла с пробелами превратится в набор строк, каждая из которых будет обрабатываться скриптом отдельно. И если в данном примере это относительно безопасно, то в реальных сценариях это может привести к абсолютно непредсказуемым последствиям.
Например, в нашей практике мы сталкивались со скриптом, который таким образом подсчитывал количество файлов в папке, потом сортировал их по дате создания и удалял самые старые, чтобы осталось всего N-файлов. Файл с пробелами в имени сразу грубо ломает эту логику и может привести к удалению нужных данных.
Обернуть ls *.mp4 в кавычки тоже не даст результата, так как в этом случае в качестве единой строки будет использоваться весь вывод команды.
🔹Вторая проблема – возможное наличие в имени файла управляющих и подстановочных символов. На практике встречается гораздо реже, но так как Linux вполне допускает подобные имена, то вы вполне можете с ними столкнуться, например, они могут появиться в результате ошибок в работе скриптов.
Допустим у вас есть набор файлов: 1Сезон-1Серия.mp4, 1Сезон-2Серия.mp4 и т.д. и туда случайным образом затесался файл где имя состоит из единицы и звездочки за ним. Символ звездочки будет расценен как подстановочный и ls подставит туда все попадающие под маску файлы. В результате все ваши серии попадут в вывод два раза. Как мы уже говорили, если в данном случае это безопасно, то в других сценариях может привести к различным негативным эффектам.
🔹Третья основная проблема – символы национальных алфавитов. Сейчас эта проблема отошла на второй план, но актуальной быть от этого не перестала. А причина все таже – ls и find рассчитаны на то, чтобы выводить информацию на экран.
А далее все зависит от установленной локали, если локаль не содержит символа, соответствующего его коду, то на его месте появится «крякозябкрик» или знак вопроса в ромбе, иди еще что-нибудь, а также такой символ может быть просто пропущен.
👆 Теперь о том, как сделать правильно. В оболочках POSIX, которым относится bash и его производные, есть функция позволяющая использовать в именах файлов символы подстановки, поэтому вывод никаких дополнительных команд анализировать не нужно, а переменную следует обязательно обернуть в кавычки:
for file in ./*.mp4; do
mv -f “$file” /new_path/video
done
В этом случае корректно будут отработаны и пробелы, и спецсимволы, и символы национальных алфавитов.
Также можно подстраховаться и добавить проверку на существование файла:
for file in ./*.mp4; do
[ -e "$file" ] || continue
mv -f “$file” /new_path/video
done
Если указанный файл не существует, то цикл пропустит текущую итерацию и перейдет к следующей.
👉 P.S. Почему мы заострили внимание именно на этой проблеме, а не на проверке наличия папки и наличия закрывающего слеша?
Потому что ls/find архитектурный баг скрипта, а остальное – частный случай с неправильной конфигурацией окружения.
Если Вася проследит, чтобы папка на момент запуска скрипта существовала – проблем у него не возникнет, никогда и никаких.
А вот использование ls/find для поиска файлов - это 100% проблема, заложенная архитектурно.
Если же Вася отразит в документации, мол перед запуском скрипта обязательно проверьте наличие целевой папки, то это уже будет не баг, а фича.
👍9🔥8🥱2🤡1
Gemini PRO практически даром
На рынке аккаунтов появилось интересное предложение Gemini PRO на 18 месяцев за смешные 200-300 руб. Честно. Без обмана.
Но в чем подвох, ведь не может быть все так прекрасно? А подвох в том, что это специальная акция от индийского телеком-гиганта Jio для своих пользователей. Но технически это никто не проверяет.
А продавцам это ничего не стоит, предложение бесплатное. Поэтому и цена символическая. Но тем не менее все нормально активируется и работает на текущий аккаунт, даже если у него регион отличается от Индии.
Риски? Как без них, Google может в любой момент проверить правомерность владения подпиской и заблокировать «левые» аккаунты и примеры тому уже были, не так давно массовый бан пущенных «налево» аккаунтов устраивал Perplexity.
С другой стороны, даже если и забанят – не жалко. Главное – не увлекаться, в смысле не забивать халявные 5 ТБ диска, идущие в комплекте с подпиской. А остальное некритично, можно спокойно пережить.
Как найти? На любой площадке ищем Gemini PRO на 18 месяцев. Нормальная цена 200-300 руб.
На рынке аккаунтов появилось интересное предложение Gemini PRO на 18 месяцев за смешные 200-300 руб. Честно. Без обмана.
Но в чем подвох, ведь не может быть все так прекрасно? А подвох в том, что это специальная акция от индийского телеком-гиганта Jio для своих пользователей. Но технически это никто не проверяет.
А продавцам это ничего не стоит, предложение бесплатное. Поэтому и цена символическая. Но тем не менее все нормально активируется и работает на текущий аккаунт, даже если у него регион отличается от Индии.
Риски? Как без них, Google может в любой момент проверить правомерность владения подпиской и заблокировать «левые» аккаунты и примеры тому уже были, не так давно массовый бан пущенных «налево» аккаунтов устраивал Perplexity.
С другой стороны, даже если и забанят – не жалко. Главное – не увлекаться, в смысле не забивать халявные 5 ТБ диска, идущие в комплекте с подпиской. А остальное некритично, можно спокойно пережить.
Как найти? На любой площадке ищем Gemini PRO на 18 месяцев. Нормальная цена 200-300 руб.
😁10👍7🥱1
Управляемый хаос
Много лет информационные системы строились, да и строятся, по принципу борьбы с отказами. Давайте купим «надежное» брендовое серверное железо, аппаратный RAID с батарейкой, корпус с дублирующим блоком питания и т.д. и т.п.
Все это должно уберечь нас от отказа, который в нашей парадигме – чрезвычайное происшествие со всеми вытекающими последствиями и оргвыводами.
И самое печальное в этом, что нашему брату админу тут форменный цугцванг. Чтобы ты не делал, любой твой ход только ухудшает ситуацию.
Купил недостаточно брендовое или вообще десктопное железо? А мы говорили, а мы предупреждали, надо было…
Сделал ровно наоборот? И отказ таки приключился? А теперь поясни, дорогой наш друг, ради чего мы выделили на это все такие большие деньги…
Поэтому современный подход - Design for Failure (Проектирование с расчетом на сбои) – исходит совершенно из обратных посылов. Сбои – это неотъемлемая часть нашей жизни, как природные явления за окном, бороться с ними невозможно, тем более предотвращать.
Все что может сломаться – сломается, все что может упасть – упадет, любой кто может накосячить – накосячит.
И это не выдумки теоретиков, это то, к чему пришли гиганты индустрии: Google, Facebook или Netflix. Они честно признались в том, что не могут бороться с отказами, но могут бороться с их последствиями.
Отсюда были выведены основные принципы:
🔹 Сбои неизбежны (Assume Failure): Все, что может сломаться (железо, сеть, стороннее API, человеческий фактор), обязательно сломается. Это не баг, это закон природы.
🔹 Изоляция отказов (Bulkheading): Проблема в одном модуле не должна лавинообразно уничтожать всю систему. Если «легла» рекомендательная система, корзина и оплата должны продолжать работать.
🔹 Контролируемая деградация (Graceful Degradation): Если система не может отдать пользователю идеальный результат, она должна отдать «приемлемый». Например, вместо пустой страницы показать закешированные вчерашние данные.
🔹 Автоматическое восстановление (Self-Healing): Система должна уметь сама перезапускать упавшие контейнеры, переключаться на резервные копии баз данных и отсекать проблемные узлы без звонка дежурному админу в 3 часа ночи.
И все это легко переносится на админские будни. Мы не можем обеспечить 100% надежность, брендовое железо может оказаться бракованным, аппаратный RAID развалит массив из-за бага в прошивке, ПО ляжет из-за бага в обновлении. И, наконец, добро пожаловать самая неизвестная переменная – человек, которому свойственно ошибаться.
Попытка строить системы, которые почти никогда не упадут на таком фундаменте обречены на провал. А вот исходить из того, что все упадет и сломается (или будет сломано) – трезвый современный подход.
И все инструменты для этого у администратора есть: кластеризация, HA, виртуализация и контейнеризация, распределенные хранилища, инфраструктура как код.
Да, местами сложно, местами непривычно, но именно это современное IT, с его управляемой деградацией и способностью к самовосстановлению.
Сервер СУБД сожрал всю память? Он не уронит весь стек, а просто упадет сам, а балансировщик переключит на вторую активную ноду. Сам же контейнер будет перезапущен или вообще пересоздан из эталона. И это лучше, чем слать алерт администратору в три часа ночи.
Резко выросла нагрузка? Кластер сам перераспределит нагрузку между нодами. Упала нода? Остальные подхватят упавший флаг, да сервис деградирует, но продолжит работать. Тормозит? Да! Но работает ведь! Клиенты не уходят, бизнес-процессы не останавливаются.
И админ спит ночами спокойно, упало – да и пес с ним, завтра в рабочее время разберется, нет необходимости вскакивать посреди ночи, брать такси (выпил вечером банку пива) и нестись, теряя ботинки в серверную.
Да и вообще в этой парадигме ломать полезно, у Netflix есть Chaos Monkey – специальный скрипт который в рабочее время в случайном порядке ломает ноды или виртуалки, что помогает инженерам найти слабые места в инфраструктуре и устранить их до тех пор, пока это станет проблемой.
Много лет информационные системы строились, да и строятся, по принципу борьбы с отказами. Давайте купим «надежное» брендовое серверное железо, аппаратный RAID с батарейкой, корпус с дублирующим блоком питания и т.д. и т.п.
Все это должно уберечь нас от отказа, который в нашей парадигме – чрезвычайное происшествие со всеми вытекающими последствиями и оргвыводами.
И самое печальное в этом, что нашему брату админу тут форменный цугцванг. Чтобы ты не делал, любой твой ход только ухудшает ситуацию.
Купил недостаточно брендовое или вообще десктопное железо? А мы говорили, а мы предупреждали, надо было…
Сделал ровно наоборот? И отказ таки приключился? А теперь поясни, дорогой наш друг, ради чего мы выделили на это все такие большие деньги…
Поэтому современный подход - Design for Failure (Проектирование с расчетом на сбои) – исходит совершенно из обратных посылов. Сбои – это неотъемлемая часть нашей жизни, как природные явления за окном, бороться с ними невозможно, тем более предотвращать.
Все что может сломаться – сломается, все что может упасть – упадет, любой кто может накосячить – накосячит.
И это не выдумки теоретиков, это то, к чему пришли гиганты индустрии: Google, Facebook или Netflix. Они честно признались в том, что не могут бороться с отказами, но могут бороться с их последствиями.
Отсюда были выведены основные принципы:
🔹 Сбои неизбежны (Assume Failure): Все, что может сломаться (железо, сеть, стороннее API, человеческий фактор), обязательно сломается. Это не баг, это закон природы.
🔹 Изоляция отказов (Bulkheading): Проблема в одном модуле не должна лавинообразно уничтожать всю систему. Если «легла» рекомендательная система, корзина и оплата должны продолжать работать.
🔹 Контролируемая деградация (Graceful Degradation): Если система не может отдать пользователю идеальный результат, она должна отдать «приемлемый». Например, вместо пустой страницы показать закешированные вчерашние данные.
🔹 Автоматическое восстановление (Self-Healing): Система должна уметь сама перезапускать упавшие контейнеры, переключаться на резервные копии баз данных и отсекать проблемные узлы без звонка дежурному админу в 3 часа ночи.
И все это легко переносится на админские будни. Мы не можем обеспечить 100% надежность, брендовое железо может оказаться бракованным, аппаратный RAID развалит массив из-за бага в прошивке, ПО ляжет из-за бага в обновлении. И, наконец, добро пожаловать самая неизвестная переменная – человек, которому свойственно ошибаться.
Попытка строить системы, которые почти никогда не упадут на таком фундаменте обречены на провал. А вот исходить из того, что все упадет и сломается (или будет сломано) – трезвый современный подход.
И все инструменты для этого у администратора есть: кластеризация, HA, виртуализация и контейнеризация, распределенные хранилища, инфраструктура как код.
Да, местами сложно, местами непривычно, но именно это современное IT, с его управляемой деградацией и способностью к самовосстановлению.
Сервер СУБД сожрал всю память? Он не уронит весь стек, а просто упадет сам, а балансировщик переключит на вторую активную ноду. Сам же контейнер будет перезапущен или вообще пересоздан из эталона. И это лучше, чем слать алерт администратору в три часа ночи.
Резко выросла нагрузка? Кластер сам перераспределит нагрузку между нодами. Упала нода? Остальные подхватят упавший флаг, да сервис деградирует, но продолжит работать. Тормозит? Да! Но работает ведь! Клиенты не уходят, бизнес-процессы не останавливаются.
И админ спит ночами спокойно, упало – да и пес с ним, завтра в рабочее время разберется, нет необходимости вскакивать посреди ночи, брать такси (выпил вечером банку пива) и нестись, теряя ботинки в серверную.
Да и вообще в этой парадигме ломать полезно, у Netflix есть Chaos Monkey – специальный скрипт который в рабочее время в случайном порядке ломает ноды или виртуалки, что помогает инженерам найти слабые места в инфраструктуре и устранить их до тех пор, пока это станет проблемой.
👍27❤1
Лог включен, но мало помогает
Именно такой ответ мы получили на предложение одному из наших читателей включить лог, чтобы он помог разобраться в проблеме.
И, к сожалению, подобные отзывы не единичны. Многие считают, что лог должен… А вот что он должен?
А лог не должен никому и ничего, это записи состояний и событий системы, которые могут оказаться вам полезны, а могут быть полностью бесполезными.
Почему так? Начнем с самого лога. Чтобы лог приносил пользу – он должен содержать записи об интересующих нас событиях. А для этого нужно правильно настроить подробность лога.
Многие системы по умолчанию записывают в лог только ошибки и предупреждения, отладочной информации в них нет. Поэтому, если нам не хватает информации – увеличиваем подробность лога.
Другая ошибка – излишние подробности, в этом случае вы просто тонете в малозначительных записях и можете пропустить действительно важное событие или не сможете провести причинно-следственные связи между несколькими событиями. В этом случае нужно наоборот уменьшить подробность логирования.
Еще одна классическая ошибка – смотрим не туда. Чаще всего это связано с тем, что «ошибка» в понимании пользователя не является ошибкой для сервиса и соответственно вы не увидите никакой записи об ошибке в таком случае.
Характерный пример – это состояния HTTP, многие из которых воспринимаются клиентом именно как ошибки. Но для самой системы это вполне допустимые и документированные состояния, которые являются частью штатного рабочего процесса.
В результате получается, что мы ищем то, чего нет. Поэтому не следует ограничивать себя каким-то фильтром или иным отбором по некоторым условиям, которые могут не совсем соответствовать или совсем не соответствовать реальной ситуации.
Поэтому, если в логе тишина, то это не значит, что лог плохой или сервис работает неправильно, а значит, что вы, скорее всего, не туда смотрите.
А смотреть надо в корень – на событие, которое должно вызвать реакцию сервиса. И начинать плясать от печки, т.е. от той системы – которое это событие инициализировала, а не от той, которая должна обработать.
Это позволяет быстро и эффективно выявить ситуации, когда мы обращаемся не туда или не так. Например, как это часто бывает, ваши запросы блокируются брандмауэром, а вы пытаетесь безрезультатно терзать веб-сервер.
Поэтому всегда нужно двигаться от источника события к результату, от локальной системы к удаленной, но не наоборот.
А еще – логи нужно уметь читать. Мы сейчас не будем брать во внимание крайний случай, когда квалификации явно недостаточно и все написанное в логе является «китайской грамотой».
Очень часто при анализе логов коллеги зацикливаются именно на самом событии и пытаются искать именно его описание, часто безрезультатно, но совершенно не обращают внимание на контекст, а ведь именно контекст определяет смысл происходящих событий.
Иногда достаточно промотать десяток строк вверх или вниз от события, чтобы понять, что именно на самом деле происходило в системе. И именно для этого бывает нужно увеличить подробности лога.
Но даже если в логе нет прямых указаний, то всегда следует обращать внимание на повторяющиеся события. Если у вас перед ошибкой раз за разом происходят еще некоторые действия – то именно они могут служить причиной ошибки и заслуживают самого пристального внимания, даже если на первый взгляд с ошибкой никак не связаны.
И помните, сам себя лог не прочитает и его отсутствие или наличие никак на работу системы не влияет. Лог нужен именно вам и нужен для того, чтобы вдумчиво его читать и анализировать. Также вы должны хотя бы в общих чертах понимать, что там написано и как вообще вся эта система работает.
Да, сегодня у нас есть неплохой помощник в виде ИИ, но без самостоятельного понимания он может направить вас на неверный путь, особенно если вы «скормите» ему не ту часть лога или начнете задавать не те вопросы.
Поэтому просто включить лог – это мало, нужно понимать что именно вы хотите в нем увидеть и почему именно в нем.
Именно такой ответ мы получили на предложение одному из наших читателей включить лог, чтобы он помог разобраться в проблеме.
И, к сожалению, подобные отзывы не единичны. Многие считают, что лог должен… А вот что он должен?
А лог не должен никому и ничего, это записи состояний и событий системы, которые могут оказаться вам полезны, а могут быть полностью бесполезными.
Почему так? Начнем с самого лога. Чтобы лог приносил пользу – он должен содержать записи об интересующих нас событиях. А для этого нужно правильно настроить подробность лога.
Многие системы по умолчанию записывают в лог только ошибки и предупреждения, отладочной информации в них нет. Поэтому, если нам не хватает информации – увеличиваем подробность лога.
Другая ошибка – излишние подробности, в этом случае вы просто тонете в малозначительных записях и можете пропустить действительно важное событие или не сможете провести причинно-следственные связи между несколькими событиями. В этом случае нужно наоборот уменьшить подробность логирования.
Еще одна классическая ошибка – смотрим не туда. Чаще всего это связано с тем, что «ошибка» в понимании пользователя не является ошибкой для сервиса и соответственно вы не увидите никакой записи об ошибке в таком случае.
Характерный пример – это состояния HTTP, многие из которых воспринимаются клиентом именно как ошибки. Но для самой системы это вполне допустимые и документированные состояния, которые являются частью штатного рабочего процесса.
В результате получается, что мы ищем то, чего нет. Поэтому не следует ограничивать себя каким-то фильтром или иным отбором по некоторым условиям, которые могут не совсем соответствовать или совсем не соответствовать реальной ситуации.
Поэтому, если в логе тишина, то это не значит, что лог плохой или сервис работает неправильно, а значит, что вы, скорее всего, не туда смотрите.
А смотреть надо в корень – на событие, которое должно вызвать реакцию сервиса. И начинать плясать от печки, т.е. от той системы – которое это событие инициализировала, а не от той, которая должна обработать.
Это позволяет быстро и эффективно выявить ситуации, когда мы обращаемся не туда или не так. Например, как это часто бывает, ваши запросы блокируются брандмауэром, а вы пытаетесь безрезультатно терзать веб-сервер.
Поэтому всегда нужно двигаться от источника события к результату, от локальной системы к удаленной, но не наоборот.
А еще – логи нужно уметь читать. Мы сейчас не будем брать во внимание крайний случай, когда квалификации явно недостаточно и все написанное в логе является «китайской грамотой».
Очень часто при анализе логов коллеги зацикливаются именно на самом событии и пытаются искать именно его описание, часто безрезультатно, но совершенно не обращают внимание на контекст, а ведь именно контекст определяет смысл происходящих событий.
Иногда достаточно промотать десяток строк вверх или вниз от события, чтобы понять, что именно на самом деле происходило в системе. И именно для этого бывает нужно увеличить подробности лога.
Но даже если в логе нет прямых указаний, то всегда следует обращать внимание на повторяющиеся события. Если у вас перед ошибкой раз за разом происходят еще некоторые действия – то именно они могут служить причиной ошибки и заслуживают самого пристального внимания, даже если на первый взгляд с ошибкой никак не связаны.
И помните, сам себя лог не прочитает и его отсутствие или наличие никак на работу системы не влияет. Лог нужен именно вам и нужен для того, чтобы вдумчиво его читать и анализировать. Также вы должны хотя бы в общих чертах понимать, что там написано и как вообще вся эта система работает.
Да, сегодня у нас есть неплохой помощник в виде ИИ, но без самостоятельного понимания он может направить вас на неверный путь, особенно если вы «скормите» ему не ту часть лога или начнете задавать не те вопросы.
Поэтому просто включить лог – это мало, нужно понимать что именно вы хотите в нем увидеть и почему именно в нем.
👍11❤2👌2🥱1
Самодеятельность, художественная и не очень
Скрипты, как много в этом слове. Я думаю, что у каждого сисадмина в жизни был период, когда он на каждый чих сочинял собственный скрипт.
Как будто это что-то плохое, скажет иной читатель. Ну, это как посмотреть, с какой точки зрения.
Начнем с точки зрения самого админа, если админ постоянный, на зарплате, то ему может показаться что ничего страшного в этом нет. Инфраструктура моя, скрипты мои, я все знаю, что может пойти не так?
Мы уже промолчим о том, что все скрипты должны быть документированы. По факту это очень и очень больной вопрос. Даже если изначальная версия скрипта таки прокомментирована и задокументирована, то последующие правки в него этого часто не удостаиваются, особенно мелкие и срочные. Потом это все копится и накладывается, ну вы поняли…
Так в чем же проблема собственных скриптов? Основная проблема в «эффекте автобуса», да да, это про того самого разработчика, который попал под автобус. Причем понимать это надо не буквально, а в том смысле, что неожиданный уход разработчика из проекта делает все эти скрипты бомбой замедленного действия.
Почему так? Про неполноту документации мы уже писали. К этому накладывается еще и дополнительный эффект «это все знают». Разработчик мог вполне сознательно опустить в документации некоторые, очевидные для него, моменты. Которые могут оказаться непонятны окружающим.
Далее сами скрипты. Очень многие скриптовые языки позволяют писать двумя способами: быстро, рационально, но нечитаемо или долго, неоптимально, но читаемо. Надо ли говорить, что чаще всего превалирует первый подход, особенно среди админов-«староверов», которые не используют современные среды разработки с синтаксис-помощниками и автодополнением, а ваяют скрипты буквально на коленках.
Мы, как аутсорсеры, очень часто встречались с такими скриптами, про которые никто ничего не знает и трогать откровенно боится, а написавший их товарищ давно растворился в тумане.
Разобраться с ними за разумное время и деньги не представляется возможным. Но самая «мякотка» состоит в том, что они дублируют те возможности и функции, которые могут быть получены штатными пакетами или распространенным и широко известным сторонним софтом.
Да ладно, снова скажет кто-то, зачем тащить целый пакет, когда тут можно десятком другим строк обойтись.
А вот и нет, пакет тащить нужно, потому что пакет - это ожидаемые конфигурация и поведение системы, в отличие от скрипта. И не важно, что это не красиво, не оптимально, не эффективно, не соответствуем вашим религиозным воззрениями (нужное подчеркнуть).
Причем наступить на эти грабли можно совершенно случайно. Для этого не нужно даже попадать под автобус. Достаточно уехать в отпуск и оказаться на некоторое время без связи.
Если в это время возникнет некоторая нештатная ситуация и коллеги не смогут разобраться в вашем творчестве, то по возвращению вас ждет достаточно неприятный разговор.
Потому что платят вам не за смелые эксперименты и самовыражение, а за поддержание инфраструктуры в стабильном, управляемом и предсказуемом виде, что подразумевает максимальную стандартизацию.
Любое нестандартное решение – это дополнительные затраты на поддержу (часто косвенные) и дополнительные риски, связанные с нестандартностью. Во многих случаях абсолютно неуместные.
А желание отдельных сотрудников использовать собственные костыли к месту и не к месту заставляет серьезно задуматься в плане их профпригодности, причем не в техническом плане (тут обычно все в порядке), а в способности работать в коллективе и ставить общественные интересы выше собственных.
Ну а мораль сей басни проста: если есть стандартные и общепринятые решения – то следует их использовать, даже если вы можете за пять минут левым задним копытом набросать скрипт «в 1000 раз лучше».
Ну или пишите и выкладывайте его на GitHub и когда его начнут включать в дистрибутивы и использовать массы – тогда можно будет использовать его как стандартное решение.
Скрипты, как много в этом слове. Я думаю, что у каждого сисадмина в жизни был период, когда он на каждый чих сочинял собственный скрипт.
Как будто это что-то плохое, скажет иной читатель. Ну, это как посмотреть, с какой точки зрения.
Начнем с точки зрения самого админа, если админ постоянный, на зарплате, то ему может показаться что ничего страшного в этом нет. Инфраструктура моя, скрипты мои, я все знаю, что может пойти не так?
Мы уже промолчим о том, что все скрипты должны быть документированы. По факту это очень и очень больной вопрос. Даже если изначальная версия скрипта таки прокомментирована и задокументирована, то последующие правки в него этого часто не удостаиваются, особенно мелкие и срочные. Потом это все копится и накладывается, ну вы поняли…
Так в чем же проблема собственных скриптов? Основная проблема в «эффекте автобуса», да да, это про того самого разработчика, который попал под автобус. Причем понимать это надо не буквально, а в том смысле, что неожиданный уход разработчика из проекта делает все эти скрипты бомбой замедленного действия.
Почему так? Про неполноту документации мы уже писали. К этому накладывается еще и дополнительный эффект «это все знают». Разработчик мог вполне сознательно опустить в документации некоторые, очевидные для него, моменты. Которые могут оказаться непонятны окружающим.
Далее сами скрипты. Очень многие скриптовые языки позволяют писать двумя способами: быстро, рационально, но нечитаемо или долго, неоптимально, но читаемо. Надо ли говорить, что чаще всего превалирует первый подход, особенно среди админов-«староверов», которые не используют современные среды разработки с синтаксис-помощниками и автодополнением, а ваяют скрипты буквально на коленках.
Мы, как аутсорсеры, очень часто встречались с такими скриптами, про которые никто ничего не знает и трогать откровенно боится, а написавший их товарищ давно растворился в тумане.
Разобраться с ними за разумное время и деньги не представляется возможным. Но самая «мякотка» состоит в том, что они дублируют те возможности и функции, которые могут быть получены штатными пакетами или распространенным и широко известным сторонним софтом.
Да ладно, снова скажет кто-то, зачем тащить целый пакет, когда тут можно десятком другим строк обойтись.
А вот и нет, пакет тащить нужно, потому что пакет - это ожидаемые конфигурация и поведение системы, в отличие от скрипта. И не важно, что это не красиво, не оптимально, не эффективно, не соответствуем вашим религиозным воззрениями (нужное подчеркнуть).
Причем наступить на эти грабли можно совершенно случайно. Для этого не нужно даже попадать под автобус. Достаточно уехать в отпуск и оказаться на некоторое время без связи.
Если в это время возникнет некоторая нештатная ситуация и коллеги не смогут разобраться в вашем творчестве, то по возвращению вас ждет достаточно неприятный разговор.
Потому что платят вам не за смелые эксперименты и самовыражение, а за поддержание инфраструктуры в стабильном, управляемом и предсказуемом виде, что подразумевает максимальную стандартизацию.
Любое нестандартное решение – это дополнительные затраты на поддержу (часто косвенные) и дополнительные риски, связанные с нестандартностью. Во многих случаях абсолютно неуместные.
А желание отдельных сотрудников использовать собственные костыли к месту и не к месту заставляет серьезно задуматься в плане их профпригодности, причем не в техническом плане (тут обычно все в порядке), а в способности работать в коллективе и ставить общественные интересы выше собственных.
Ну а мораль сей басни проста: если есть стандартные и общепринятые решения – то следует их использовать, даже если вы можете за пять минут левым задним копытом набросать скрипт «в 1000 раз лучше».
Ну или пишите и выкладывайте его на GitHub и когда его начнут включать в дистрибутивы и использовать массы – тогда можно будет использовать его как стандартное решение.
👍20👎6❤3🤮2🔥1
За одного битого двух небитых дают. Часть 1
Эту заметку прислал мой коллега с Урала и попросил опубликовать анонимно. История в сотню крат отражает классические грабли во взаимоотношениях ИТ и бизнеса. На мой взгляд — максимально поучительно.
Далее повествование от первого лица. Имена и места действия изменены.
В то время я был относительно молод, тридцать с небольшим. Работал на заводе системным администратором. Зарплата — не фонтан, зато стабильная, да и работой особо не заваливали. Плюс стандартные плюшки: соцпакет, предсказуемый отпуск и спокойствие. Жена как раз ушла в декрет, поэтому «синица в руках» была всяко лучше журавля, хоть временами и приходилось туго затягивать пояса.
Как-то вечером в своем районе я встретил одноклассника Сашу. Друзьями мы никогда не были, но несколько лет просидели за одной партой. Саша звезд с неба не хватал: занимался стройкой и ремонтом, а к моменту встречи открыл с компаньонами бизнес. У них было несколько строительных магазинчиков формата «все у дома» под управлением Саши и крупная торговая база за городом, которой рулили его партнеры.
Саша предложил подработку: автоматизировать магазины и настроить там нормальный учет. В свободное от завода время я как раз баловался программированием на «1С» — брал заказы на фрилансе, да и на основной работе по мелочи писал отчеты и обработки.
Понеслась. Задач подвалило много, и все интересные. Платил Саша исправно, и вскоре этот проект начал приносить мне вторую полноценную зарплату. Жить стало веселей.
Но именно тогда я допустил ряд серьезных тактических ошибок, которые жестко аукнулись мне в будущем:
1️⃣ Ошибка первая: Работа «как для себя». Я глубоко вникал в процессы и дорабатывал систему под нужды линейных сотрудников, чтобы сделать их работу проще и быстрее. Но делал это молча: никак не фиксировал, не афишировал, да никто с меня отчетов и не требовал. Всех все устраивало, деньги платились.
2️⃣ Ошибка вторая: Отсутствие учета задач. Никакой работы с обращениями не было. Проблемы решались по звонку или через удаленку в режиме «потушить пожар». Я просто брал фиксированную абонентскую плату в месяц с каждой торговой точки.
А потом от розничных магазинов я плавно перешел к автоматизации той самой загородной базы компаньонов. Это совпало со строительным бумом в регионе — бизнес начал бурно расти.
Задачи стали масштабнее, количество моих подопечных увеличилось раза в три. И вот тут начались настоящие проблемы. То, что идеально работало на маленькой сети, где все знали друг друга по именам, при масштабировании мгновенно сломалось.
Продолжение истории вечером…
Эту заметку прислал мой коллега с Урала и попросил опубликовать анонимно. История в сотню крат отражает классические грабли во взаимоотношениях ИТ и бизнеса. На мой взгляд — максимально поучительно.
Далее повествование от первого лица. Имена и места действия изменены.
В то время я был относительно молод, тридцать с небольшим. Работал на заводе системным администратором. Зарплата — не фонтан, зато стабильная, да и работой особо не заваливали. Плюс стандартные плюшки: соцпакет, предсказуемый отпуск и спокойствие. Жена как раз ушла в декрет, поэтому «синица в руках» была всяко лучше журавля, хоть временами и приходилось туго затягивать пояса.
Как-то вечером в своем районе я встретил одноклассника Сашу. Друзьями мы никогда не были, но несколько лет просидели за одной партой. Саша звезд с неба не хватал: занимался стройкой и ремонтом, а к моменту встречи открыл с компаньонами бизнес. У них было несколько строительных магазинчиков формата «все у дома» под управлением Саши и крупная торговая база за городом, которой рулили его партнеры.
Саша предложил подработку: автоматизировать магазины и настроить там нормальный учет. В свободное от завода время я как раз баловался программированием на «1С» — брал заказы на фрилансе, да и на основной работе по мелочи писал отчеты и обработки.
Понеслась. Задач подвалило много, и все интересные. Платил Саша исправно, и вскоре этот проект начал приносить мне вторую полноценную зарплату. Жить стало веселей.
Но именно тогда я допустил ряд серьезных тактических ошибок, которые жестко аукнулись мне в будущем:
1️⃣ Ошибка первая: Работа «как для себя». Я глубоко вникал в процессы и дорабатывал систему под нужды линейных сотрудников, чтобы сделать их работу проще и быстрее. Но делал это молча: никак не фиксировал, не афишировал, да никто с меня отчетов и не требовал. Всех все устраивало, деньги платились.
2️⃣ Ошибка вторая: Отсутствие учета задач. Никакой работы с обращениями не было. Проблемы решались по звонку или через удаленку в режиме «потушить пожар». Я просто брал фиксированную абонентскую плату в месяц с каждой торговой точки.
А потом от розничных магазинов я плавно перешел к автоматизации той самой загородной базы компаньонов. Это совпало со строительным бумом в регионе — бизнес начал бурно расти.
Задачи стали масштабнее, количество моих подопечных увеличилось раза в три. И вот тут начались настоящие проблемы. То, что идеально работало на маленькой сети, где все знали друг друга по именам, при масштабировании мгновенно сломалось.
Продолжение истории вечером…
👍12❤8🤔5🥱4👌1
За одного битого двух небитых дают. Часть 2
Проблемы стали расти как снежный ком. Они больше не купировались на нижнем уровне, а летели прямиком к руководству. С программой тоже начался ад. Не секрет, что УТ 11 — конфигурация весьма специфическая. После древней, но понятной ТиС 9.7, которая стояла там раньше, глухое недовольство пользователей было абсолютно ожидаемым.
Контора бурно росла, появлялись новые люди. Меня они видели впервые, поэтому быстро предложили руководству: «А давайте позовём независимый аудит?»
В качестве «независимого светила» нашелся ведущий преподаватель местного учебного центра «1С», обвешанный сертификатами по самое не балуйся.
На встрече он разнес меня в пух и прах: «Всё написано не по методикам! Конфигурацию тупо изуродовали! Для чего это сделано? Зачем?» А я сидел, обтекая, и мотивированно ответить мне было нечем…
К счастью, собственники бизнеса оказались парнями хоть и простыми, но далеко не глупыми. Они предложили проверить теорию практикой: «Берем два компьютера. На один ставим "изуродованную" программу автора, на второй — чистую, но настроенную по методике эксперта».
«Светило» с темы технично съехало — мол, не барское это дело. В итоге оба стенда я собирал сам. Результат оказался предсказуем. Вердикт вынесли в мою пользу: «Косяки у автора есть, не без этого. Но в штатной "коробочной" версии вообще финиш — мы там соберем очереди как в мавзолей, а то, что сейчас делается за день, будет занимать неделю».
Когда мы вышли покурить с Сашей, я не выдержал и упрекнул его: «Чего ты сидел и молчал, пока меня ссаной тряпкой по морде возили? Обидно вообще-то. Столько впахивал, делал как для себя!»
И тут Саша выдал абсолютно резонную вещь, которая перевернула мое понимание ИТ-архитектуры. Он сказал, что не молчал, а слушал. А то, что я делал «как для себя» и не ставил их в известность — это огромная ошибка.
«Во-первых, мы понятия не имели, что в программе было изначально, а что добавил ты. Во-вторых, ты не владелец бизнеса и смотришь со своей колокольни. Максимум, что ты можешь потерять — это сумму в месяц. Все остальные издержки лягут на меня. Ты же не будешь кормить моих детей и платить зарплату моим сотрудникам?»
Мне нечего было возразить.
С тех пор правила игры жестко изменились. Теперь все идеи, проблемы и доработки идут строго через верх, санкционируются руководством и только потом спускаются вниз. Такой подход позволяет директорам четко видеть: окупаются ли доработки и использует ли их персонал.
И теперь на классическое нытье линейщиков: «А тут у нас… Это… Того… Не работает!» — у руководства сразу готов ответ: «Вам под эту задачу неделю назад кнопку вывели и инструкции на почту скинули. Почему не пользуемся?»
Это гораздо лучше ситуации, когда сотрудники бегут жаловаться начальству, а руководство косо смотрит на админа, который «изуродовал» систему.
Но самый главный мой косяк был в другом: я вовремя не донес до руководства истинное положение дел на низах. Пока я героически тушил пожары в одиночку, у боссов была иллюзия, что проблем нет — ни с людьми, ни с процессами, ни с софтом. А когда при масштабировании всё это разом выплеснулось наружу, на меня вылили ушат холодной воды, и оправдываться пришлось мне.
Как дела обстоят сейчас:
1️⃣ Тотальный учет: Каждое обращение тщательно фиксируется, систематизируется и раз в месяц ложится на стол собственникам с моими выводами.
2️⃣ Платная поддержка: Все заявки теперь оплачиваются отдельно, и я не боюсь обсуждать их с бизнесом.
3️⃣ Разделение логики: Там, где виной человеческий фактор, руководство включает материальную мотивацию (штрафы/премии). Там, где можно помочь технически — я пилю доработки.
👆 Главный урок, который я вынес: всё, что вы делаете для бизнеса (неважно, на фрилансе или в штате), должно учитываться, документироваться и согласовываться наверху. У руководства должна быть полная картина. Иначе однажды бизнесу откроется весь пласт накопившихся проблем, а крайним сделают вас — просто потому, что вы замкнули всё на себя и вовремя никого не предупредили.
Проблемы стали расти как снежный ком. Они больше не купировались на нижнем уровне, а летели прямиком к руководству. С программой тоже начался ад. Не секрет, что УТ 11 — конфигурация весьма специфическая. После древней, но понятной ТиС 9.7, которая стояла там раньше, глухое недовольство пользователей было абсолютно ожидаемым.
Контора бурно росла, появлялись новые люди. Меня они видели впервые, поэтому быстро предложили руководству: «А давайте позовём независимый аудит?»
В качестве «независимого светила» нашелся ведущий преподаватель местного учебного центра «1С», обвешанный сертификатами по самое не балуйся.
На встрече он разнес меня в пух и прах: «Всё написано не по методикам! Конфигурацию тупо изуродовали! Для чего это сделано? Зачем?» А я сидел, обтекая, и мотивированно ответить мне было нечем…
К счастью, собственники бизнеса оказались парнями хоть и простыми, но далеко не глупыми. Они предложили проверить теорию практикой: «Берем два компьютера. На один ставим "изуродованную" программу автора, на второй — чистую, но настроенную по методике эксперта».
«Светило» с темы технично съехало — мол, не барское это дело. В итоге оба стенда я собирал сам. Результат оказался предсказуем. Вердикт вынесли в мою пользу: «Косяки у автора есть, не без этого. Но в штатной "коробочной" версии вообще финиш — мы там соберем очереди как в мавзолей, а то, что сейчас делается за день, будет занимать неделю».
Когда мы вышли покурить с Сашей, я не выдержал и упрекнул его: «Чего ты сидел и молчал, пока меня ссаной тряпкой по морде возили? Обидно вообще-то. Столько впахивал, делал как для себя!»
И тут Саша выдал абсолютно резонную вещь, которая перевернула мое понимание ИТ-архитектуры. Он сказал, что не молчал, а слушал. А то, что я делал «как для себя» и не ставил их в известность — это огромная ошибка.
«Во-первых, мы понятия не имели, что в программе было изначально, а что добавил ты. Во-вторых, ты не владелец бизнеса и смотришь со своей колокольни. Максимум, что ты можешь потерять — это сумму в месяц. Все остальные издержки лягут на меня. Ты же не будешь кормить моих детей и платить зарплату моим сотрудникам?»
Мне нечего было возразить.
С тех пор правила игры жестко изменились. Теперь все идеи, проблемы и доработки идут строго через верх, санкционируются руководством и только потом спускаются вниз. Такой подход позволяет директорам четко видеть: окупаются ли доработки и использует ли их персонал.
И теперь на классическое нытье линейщиков: «А тут у нас… Это… Того… Не работает!» — у руководства сразу готов ответ: «Вам под эту задачу неделю назад кнопку вывели и инструкции на почту скинули. Почему не пользуемся?»
Это гораздо лучше ситуации, когда сотрудники бегут жаловаться начальству, а руководство косо смотрит на админа, который «изуродовал» систему.
Но самый главный мой косяк был в другом: я вовремя не донес до руководства истинное положение дел на низах. Пока я героически тушил пожары в одиночку, у боссов была иллюзия, что проблем нет — ни с людьми, ни с процессами, ни с софтом. А когда при масштабировании всё это разом выплеснулось наружу, на меня вылили ушат холодной воды, и оправдываться пришлось мне.
Как дела обстоят сейчас:
1️⃣ Тотальный учет: Каждое обращение тщательно фиксируется, систематизируется и раз в месяц ложится на стол собственникам с моими выводами.
2️⃣ Платная поддержка: Все заявки теперь оплачиваются отдельно, и я не боюсь обсуждать их с бизнесом.
3️⃣ Разделение логики: Там, где виной человеческий фактор, руководство включает материальную мотивацию (штрафы/премии). Там, где можно помочь технически — я пилю доработки.
👆 Главный урок, который я вынес: всё, что вы делаете для бизнеса (неважно, на фрилансе или в штате), должно учитываться, документироваться и согласовываться наверху. У руководства должна быть полная картина. Иначе однажды бизнесу откроется весь пласт накопившихся проблем, а крайним сделают вас — просто потому, что вы замкнули всё на себя и вовремя никого не предупредили.
👍38🥱7🤣3❤2
Как узнать какие пакеты установлены из какого репозитория
Очень часто, наводя порядок или планируя обновление системы встает вопрос о подключенных репозиториях, в частности о том, для чего они нужны и какие пакеты из них установлены.
Прямого способа сделать это нет, но Linux тем и хорош, что позволяет решить задачу различными способами, в нашем случае мы будем использовать
Чтобы получить интересующую нас информацию прежде всего выведем список подключенных репозиториев командой:
В ее выводе нас прежде всего будет интересовать опция «источник (origin)», которая выводится после ключа
Теперь мы можем получить полный список пакетов из этого репозитория командой:
В данном случае указываем наименование источника сразу после ключа
Если репозиторий небольшой, то этого достаточно. Вы можете быстро понять, что из него уже установлено, что вы можете установить и нужно ли это вам вообще в текущий момент времени.
В противном случае нужно будет добавить дополнительные отборы, например, добавим фильтр по только установленным пакетам:
Здесь мы соединили через логическое И два условия: пакет установлен
Также обратите внимание, что имя источника не обязательно указывать полностью, так как это регулярное выражение. Так для репозитория
Но здесь нас может поджидать несколько иная сложность, среди установленных пактов нам могут попасться пакеты со статусом [установлен, автоматически] и их может быть много, очень много.
Статус [установлен, автоматически] обозначает что мы не выбирали этот пакет для установки, и он был получен автоматически, по зависимостям. Для больших репозиториев таких пакетов может оказаться сильно много, и они серьезно ухудшают восприятие. Поэтом добавим еще одно условие:
Где параметр
Данные конструкции можно использовать не только с командой
Или обратившись к подобной информации в сети интернет.
Очень часто, наводя порядок или планируя обновление системы встает вопрос о подключенных репозиториях, в частности о том, для чего они нужны и какие пакеты из них установлены.
Прямого способа сделать это нет, но Linux тем и хорош, что позволяет решить задачу различными способами, в нашем случае мы будем использовать
apt-patterns, позволяющий использовать регулярные выражения с командами apt.Чтобы получить интересующую нас информацию прежде всего выведем список подключенных репозиториев командой:
apt policy
В ее выводе нас прежде всего будет интересовать опция «источник (origin)», которая выводится после ключа
o=. Теперь мы можем получить полный список пакетов из этого репозитория командой:
apt list ~Onginx
В данном случае указываем наименование источника сразу после ключа
~O, без пробела. Обратите внимание, что данная команда выводит все пакеты, содержащиеся в репозитории, установленные пакеты при этом помечены отдельно как [установлен].Если репозиторий небольшой, то этого достаточно. Вы можете быстро понять, что из него уже установлено, что вы можете установить и нужно ли это вам вообще в текущий момент времени.
В противном случае нужно будет добавить дополнительные отборы, например, добавим фильтр по только установленным пакетам:
apt list ?and\(~i\,~Oprox\)
Здесь мы соединили через логическое И два условия: пакет установлен
~i и пакет принадлежит определенному источнику ~O, также не забывайте использовать обратный слеш для экранирования служебных символов.Также обратите внимание, что имя источника не обязательно указывать полностью, так как это регулярное выражение. Так для репозитория
o=Proxmox мы использовали просто ~Oprox.Но здесь нас может поджидать несколько иная сложность, среди установленных пактов нам могут попасться пакеты со статусом [установлен, автоматически] и их может быть много, очень много.
Статус [установлен, автоматически] обозначает что мы не выбирали этот пакет для установки, и он был получен автоматически, по зависимостям. Для больших репозиториев таких пакетов может оказаться сильно много, и они серьезно ухудшают восприятие. Поэтом добавим еще одно условие:
apt list ?and\(~i\,\!~M\,~Oprox\)
Где параметр
!~M обозначает «кроме установленных автоматически». Теперь вывод команды покажет только пакеты, которые были установлены вручную из указанного репозитория. Данные конструкции можно использовать не только с командой
apt list, но и с любыми другими командами apt, например для установки или удаления пакетов. А больше информации вы можете получить при помощи: man apt-patterns
Или обратившись к подобной информации в сети интернет.
👍15❤2🤔2
Обновляем Proxmox Mail Gateway с версии 8 до 9
Proxmox Mail Gateway - специализированное решение почтового шлюза для фильтрации входящих и исходящих потоков почты эффективно защищающее от спама и вредоносных вложений.
Продукт бесплатный и простой в развертывании, при этом способный закрыть потребности как малого бизнеса, так и крупных предприятий.
Сегодня мы расскажем как обновить его до последней версии, материал основан на официальной документации и дополнен собственным опытом.
✅ Читать далее: https://interface31.ru/post/obnovlyaem-proxmox-mail-gateway-s-versii-8-do-9/
Proxmox Mail Gateway - специализированное решение почтового шлюза для фильтрации входящих и исходящих потоков почты эффективно защищающее от спама и вредоносных вложений.
Продукт бесплатный и простой в развертывании, при этом способный закрыть потребности как малого бизнеса, так и крупных предприятий.
Сегодня мы расскажем как обновить его до последней версии, материал основан на официальной документации и дополнен собственным опытом.
✅ Читать далее: https://interface31.ru/post/obnovlyaem-proxmox-mail-gateway-s-versii-8-do-9/
👍10
Какие признаки выхода из строя можно увидеть в SMART NVMe-диска
NVMe-диски имеют совершенно иной, собственный SMART, разработанный для твердотельных накопителей, а не унаследованный от жестких дисков и содержит достаточно простые и понятные показатели, а также отдельный параметр Critical Warning для отображения критических состояний.
Но, как это чаще всего бывает, диск умирает, когда ничто не предвещает беды. Вроде и SMART отличный, а диск все равно умер. Ситуация знакомая еще по жестким дискам и сразу скажем, что SMART – это не панацея, но есть определенные параметры, изменение которых может указывать на проблемы с диском.
Начнем со следующей пары:
🔹 Media and Data Integrity Errors - ошибки целостности данных и носителя – данный счетчик фиксирует случаи, когда информация из ячейки не смогла быть прочитана и восстановлена при помощи механизмов коррекции. Указывает на ошибки и износ памяти.
🔹 Error Information Log Entries - записи в журнале ошибок – это другой тип ошибок, происходящих на уровне общения диска с внешним миром, могут указывать на кривые драйвера, плохой разъем, перегрев и ошибки контроллера и не обязательно означают неисправность самого диска.
Поэтому если у вас начал расти первый показатель – это повод серьезно напрячься и задуматься о дальнейшем здоровье диска. Если растет второй – то прежде всего изучите внешние условия и режимы эксплуатации, скорее всего проблема не в самом диске, а в окружающей инфраструктуре.
Также крайне полезно контролировать еще один параметр:
🔹 Available Spare - количество запасных ячеек, в норме это значение равно 100%.
Есть еще один связанный параметр - Available Spare Threshold – который показывает при снижении запасных ячеек до какого количества диск выбросит критическую ошибку, разные производители устанавливают разные значения: от 1% до 10%.
Если же у нас вместе с ростом Media and Data Integrity Errors наблюдается падение Available Spare – то можно говорить о том, что диск посыпался и его следует заменить. Не ждите появления критической ошибки, если процесс пошел, то в какой-то момент он может начать развиваться лавинообразно и до предупреждения диск может не дожить.
В ответственных системах следует поставить эти два показателя на мониторинг.
NVMe-диски имеют совершенно иной, собственный SMART, разработанный для твердотельных накопителей, а не унаследованный от жестких дисков и содержит достаточно простые и понятные показатели, а также отдельный параметр Critical Warning для отображения критических состояний.
Но, как это чаще всего бывает, диск умирает, когда ничто не предвещает беды. Вроде и SMART отличный, а диск все равно умер. Ситуация знакомая еще по жестким дискам и сразу скажем, что SMART – это не панацея, но есть определенные параметры, изменение которых может указывать на проблемы с диском.
Начнем со следующей пары:
🔹 Media and Data Integrity Errors - ошибки целостности данных и носителя – данный счетчик фиксирует случаи, когда информация из ячейки не смогла быть прочитана и восстановлена при помощи механизмов коррекции. Указывает на ошибки и износ памяти.
🔹 Error Information Log Entries - записи в журнале ошибок – это другой тип ошибок, происходящих на уровне общения диска с внешним миром, могут указывать на кривые драйвера, плохой разъем, перегрев и ошибки контроллера и не обязательно означают неисправность самого диска.
Поэтому если у вас начал расти первый показатель – это повод серьезно напрячься и задуматься о дальнейшем здоровье диска. Если растет второй – то прежде всего изучите внешние условия и режимы эксплуатации, скорее всего проблема не в самом диске, а в окружающей инфраструктуре.
Также крайне полезно контролировать еще один параметр:
🔹 Available Spare - количество запасных ячеек, в норме это значение равно 100%.
Есть еще один связанный параметр - Available Spare Threshold – который показывает при снижении запасных ячеек до какого количества диск выбросит критическую ошибку, разные производители устанавливают разные значения: от 1% до 10%.
Если же у нас вместе с ростом Media and Data Integrity Errors наблюдается падение Available Spare – то можно говорить о том, что диск посыпался и его следует заменить. Не ждите появления критической ошибки, если процесс пошел, то в какой-то момент он может начать развиваться лавинообразно и до предупреждения диск может не дожить.
В ответственных системах следует поставить эти два показателя на мониторинг.
👍17👌14❤1👨💻1
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍18🤮2❤1👌1
🚀 26 лет — и уже тимлид в ИТ. Как это возможно?
Многие думают, что до хорошей зарплаты в разработке нужно идти десятилетиями.
Но путь может быть быстрее, если с первых лет учёбы получать опыт, делать проекты и работать с реальными задачами.
Как выглядит грамотный карьерный трек в ИТ — разобрали в МАП 👇
🔗 Читать
#реклама
О рекламодателе
Многие думают, что до хорошей зарплаты в разработке нужно идти десятилетиями.
Но путь может быть быстрее, если с первых лет учёбы получать опыт, делать проекты и работать с реальными задачами.
Как выглядит грамотный карьерный трек в ИТ — разобрали в МАП 👇
🔗 Читать
#реклама
О рекламодателе
🤡8
Zabbix – а куда делся мой ресурс SSD?
Жил был Zabbix и его судьба, как это обычно случается, была трудна. Вначале, он как Сирота Казанская жил, где придется, потом, кое-как обрел свой угол, где и обретался худо-бедно…
Потом администраторам приблудился компьютер, не самый плохой, что-то типа Ryzen 5, и они подумали – если он никому не нужен, то сделаем на нем свой сервер и соберем на него всякие админские штуки, тот же Zabbix, чего он там по закоулкам тусуется.
Сказано – сделано. Докупили память, новые NVMe диски, поставили Proxmox и запустили это все в эксплуатацию.
А третьего дня сильно удивились – а куда делся ресурс SSD? За четыре с небольшим месяца (131 день) кто-то скушал 79% ресурса SSD. Диски, так как серьезной нагрузки не предполагалось, брали недорогие, Kingston NV2 500 ГБ с TBW 160 ТБ.
Несложный подсчет показал, что ежесуточный объем записи на диски составил 745 ГБ и основной виновник в этом – процесс MySQL обслуживающий Zabbix. Если продолжать такими темпами, то дисков хватит еще на два месяца.
👆 Мораль? Изучайте потребности собственных приложений в ресурсах перед покупкой комплектующих, а не после. И да, диск – это расходный материал.
Жил был Zabbix и его судьба, как это обычно случается, была трудна. Вначале, он как Сирота Казанская жил, где придется, потом, кое-как обрел свой угол, где и обретался худо-бедно…
Потом администраторам приблудился компьютер, не самый плохой, что-то типа Ryzen 5, и они подумали – если он никому не нужен, то сделаем на нем свой сервер и соберем на него всякие админские штуки, тот же Zabbix, чего он там по закоулкам тусуется.
Сказано – сделано. Докупили память, новые NVMe диски, поставили Proxmox и запустили это все в эксплуатацию.
А третьего дня сильно удивились – а куда делся ресурс SSD? За четыре с небольшим месяца (131 день) кто-то скушал 79% ресурса SSD. Диски, так как серьезной нагрузки не предполагалось, брали недорогие, Kingston NV2 500 ГБ с TBW 160 ТБ.
Несложный подсчет показал, что ежесуточный объем записи на диски составил 745 ГБ и основной виновник в этом – процесс MySQL обслуживающий Zabbix. Если продолжать такими темпами, то дисков хватит еще на два месяца.
👆 Мораль? Изучайте потребности собственных приложений в ресурсах перед покупкой комплектующих, а не после. И да, диск – это расходный материал.
👍12🤡1
«Столото» — тысячи точек продаж и миллионы игроков онлайн, инфраструктура, которой нельзя останавливаться. Свой SOC у команды уже был, но число и сложность атак росли — мониторинг и реагирование нужно было усиливать.
Решением стал круглосуточный сервис F6 SOC MDR. Он не заменил внутреннюю команду, а стал её продолжением: развёрнут XDR-контур, взят под контроль внешний периметр с помощью решения ASM и бесшовно подключена действующая SIEM.
В результате — единый контур управления инцидентами и сокращение времени реакции на нейтрализацию угроз, что позволило ИБ-команде заниматься стратегией, а не разбором потока алертов.
Полная история и комментарий CISO «Столото» — на сайте
#реклама
О рекламодателе
Решением стал круглосуточный сервис F6 SOC MDR. Он не заменил внутреннюю команду, а стал её продолжением: развёрнут XDR-контур, взят под контроль внешний периметр с помощью решения ASM и бесшовно подключена действующая SIEM.
В результате — единый контур управления инцидентами и сокращение времени реакции на нейтрализацию угроз, что позволило ИБ-команде заниматься стратегией, а не разбором потока алертов.
Полная история и комментарий CISO «Столото» — на сайте
#реклама
О рекламодателе
🤮1