Резервное копирование файловых баз 1С:Предприятие в S3 хранилище
Данную заметку мы начнем с описания проблематики, потому как она достаточно специфична и именно ей обусловлены принятые нами при разработке скрипта решения.
Файловые базы – это малый или даже средний бизнес, вполне нормальные и платежеспособные клиенты, но с одной особенностью – 1С:Предприятие нужна только для отчетности и зарплаты, поэтому работают с ней пару-тройку человек, преимущественно удаленно.
Сегодня стандарт де-факто – это публикация файловой базы на веб-сервере, что обеспечивает нормальный уровень производительности и спокойно позволяет организовать удаленный доступ к ней без лишних затрат.
Кроме этого, всегда будет хотя бы одно место, как правило, локальное, к которому база подключена напрямую, это связано с необходимостью устанавливать патчи, обновления, расширения и т.д.
На все это накладывается неопределенный режим работы и отсутствие четкого технологического окна. Градации там могут быть разные, от включен постоянно, до утром включили, вечером выключили.
Поэтому угадать время, когда в базе никого нет сложно, даже глухой ночью может висеть активный сеанс, хорошо если он ничего не делает, а если там групповое перепроведение или еще какая обработка запущена?
И если веб-сеансы мы можем относительно безопасно для базы отключить, то завершить локальный сеанс безопасно невозможно, только завершением процесса 1С. А это может привести к совершенно разным последствиям.
Поэтому нам нужно выгружать копию безопасно и не выгоняя пользователей, такой способ есть – Автономный сервер 1С:Предприятие, он позволяет выгрузить дамп базы – DT, не выгоняя пользователей.
Насколько корректна будет такая выгрузка? С точки зрения физической структуры это будет нормальный, полноценный дамп.
С логической? Целостность дампа сохраняется на момент его создания, если в это время в базе работали или была запущена незавершенная транзакция, то дамп будет неконсистентным.
В обычных СУБД такие вопросы решаются автоматически, в файловой 1С вам поможет проверка логической целостности в конфигураторе. Но в любом случае у вас будет рабочая база, просто без части данных.
Но ровно тоже самое вы получите и при использовании pg_dump или простой модели восстановления MS SQL, так что тут полный паритет. Да и не нужно небольшим базам восстановление на момент времени.
Также стоит помнить, что DT – это сырой дамп, а не резервная копия и сам вендор обращает на это внимание, вы можете спокойно выгрузить DT из поврежденной базе, который потом не сможете загрузить.
Но в нашем сценарии DT – это оптимальный вариант, в том числе и потому, что мы можем назвать файл как нам нравится, а для его загрузки надо запустить нужную базу в конфигураторе.
В то время как сам файл базы зовется исключительно 1Cv8.1CD и ничего не стоит перепутать файлы или заменить не тот файл, а такие случаи на нашем опыте случались не раз и не два.
Теперь почему S3 – сегодня это самый дешевый способ внешнего хранения данных и один из самых безопасных, особенно если хранилище поддерживает версионирование.
В итоге, собрав все эти требования воедино и приведя к единому знаменателю мы совместно с Claude написали и отладили скрипт. Скрипт писали «по-взрослому», все настройки хранятся в отдельных файлах, сам скрипт вам трогать не нужно.
В комплекте у вас будет 4 файла:
▫️Backup-1C-ToS3.ps1 – сам скрипт
▫️Backup-1C-ToS3.bat – файл-стартер для ручного запуска
▫️config.ini – настройки подключения к S3-хранилищу
▫️databases.lst – список файловых баз, пути к ним и учетные данные для входа
Все файлы отлично прокомментированы и содержат краткие инструкции по применению. Единственный момент, так как писалось все это конкретно под S3 Selectel, то в комментах и примерах фигурирует именно он, но скрипт будет работать с любым S3 хранилищем.
Из зависимостей вам потребуется Автономный сервер (устанавливается с компонентой сервера 1С, если сервер не нужен снимите флаг его установки в качестве службы) и AWS CLI.
Данную заметку мы начнем с описания проблематики, потому как она достаточно специфична и именно ей обусловлены принятые нами при разработке скрипта решения.
Файловые базы – это малый или даже средний бизнес, вполне нормальные и платежеспособные клиенты, но с одной особенностью – 1С:Предприятие нужна только для отчетности и зарплаты, поэтому работают с ней пару-тройку человек, преимущественно удаленно.
Сегодня стандарт де-факто – это публикация файловой базы на веб-сервере, что обеспечивает нормальный уровень производительности и спокойно позволяет организовать удаленный доступ к ней без лишних затрат.
Кроме этого, всегда будет хотя бы одно место, как правило, локальное, к которому база подключена напрямую, это связано с необходимостью устанавливать патчи, обновления, расширения и т.д.
На все это накладывается неопределенный режим работы и отсутствие четкого технологического окна. Градации там могут быть разные, от включен постоянно, до утром включили, вечером выключили.
Поэтому угадать время, когда в базе никого нет сложно, даже глухой ночью может висеть активный сеанс, хорошо если он ничего не делает, а если там групповое перепроведение или еще какая обработка запущена?
И если веб-сеансы мы можем относительно безопасно для базы отключить, то завершить локальный сеанс безопасно невозможно, только завершением процесса 1С. А это может привести к совершенно разным последствиям.
Поэтому нам нужно выгружать копию безопасно и не выгоняя пользователей, такой способ есть – Автономный сервер 1С:Предприятие, он позволяет выгрузить дамп базы – DT, не выгоняя пользователей.
Насколько корректна будет такая выгрузка? С точки зрения физической структуры это будет нормальный, полноценный дамп.
С логической? Целостность дампа сохраняется на момент его создания, если в это время в базе работали или была запущена незавершенная транзакция, то дамп будет неконсистентным.
В обычных СУБД такие вопросы решаются автоматически, в файловой 1С вам поможет проверка логической целостности в конфигураторе. Но в любом случае у вас будет рабочая база, просто без части данных.
Но ровно тоже самое вы получите и при использовании pg_dump или простой модели восстановления MS SQL, так что тут полный паритет. Да и не нужно небольшим базам восстановление на момент времени.
Также стоит помнить, что DT – это сырой дамп, а не резервная копия и сам вендор обращает на это внимание, вы можете спокойно выгрузить DT из поврежденной базе, который потом не сможете загрузить.
Но в нашем сценарии DT – это оптимальный вариант, в том числе и потому, что мы можем назвать файл как нам нравится, а для его загрузки надо запустить нужную базу в конфигураторе.
В то время как сам файл базы зовется исключительно 1Cv8.1CD и ничего не стоит перепутать файлы или заменить не тот файл, а такие случаи на нашем опыте случались не раз и не два.
Теперь почему S3 – сегодня это самый дешевый способ внешнего хранения данных и один из самых безопасных, особенно если хранилище поддерживает версионирование.
В итоге, собрав все эти требования воедино и приведя к единому знаменателю мы совместно с Claude написали и отладили скрипт. Скрипт писали «по-взрослому», все настройки хранятся в отдельных файлах, сам скрипт вам трогать не нужно.
В комплекте у вас будет 4 файла:
▫️Backup-1C-ToS3.ps1 – сам скрипт
▫️Backup-1C-ToS3.bat – файл-стартер для ручного запуска
▫️config.ini – настройки подключения к S3-хранилищу
▫️databases.lst – список файловых баз, пути к ним и учетные данные для входа
Все файлы отлично прокомментированы и содержат краткие инструкции по применению. Единственный момент, так как писалось все это конкретно под S3 Selectel, то в комментах и примерах фигурирует именно он, но скрипт будет работать с любым S3 хранилищем.
Из зависимостей вам потребуется Автономный сервер (устанавливается с компонентой сервера 1С, если сервер не нужен снимите флаг его установки в качестве службы) и AWS CLI.
12👍22🔥9❤8🤝1
Сервис лицензирования 1С – плюсы и минусы
В обсуждениях многие упоминали и планировали развертывание сервера лицензирования 1С, поэтому мы решили отдельным материалом осветить все достоинства и недостатки такого решения.
Начнем с того, что правильно такое решение называется именно Сервис лицензирования, а не Сервер лицензирования, но второй вариант давно прижился и его также можно использовать, только следует понимать, что речь идет об одном и том же.
Сервис лицензирования представляет отдельную серверную инсталляцию в кластере серверов, которая содержит только одноименную службу (Назначение функциональности в терминах 1С) и не требует для запуска отдельной серверной лицензии.
Сервис лицензирования может выдавать серверные и клиентские многопользовательские лицензии, последние всегда выдаются только на сеанс, вне зависимости от режима подключения клиента.
Минимальные требования к сервису лицензирования – два ядра и 4 ГБ оперативной памяти, хотя последнее требование на наш взгляд несколько завышено.
Также следует помнить, что сервис лицензирования не работает с HASP-ключами и не может привязать лицензию к такому ключу.
Еще один важный момент – сервис лицензирования не работает с клиентскими подключениями, а выдает лицензии только серверу (серверам), который в свою очередь может выдать ее клиенту.
Версия платформы и разрядность сервиса лицензирования должна совпадать с версией платформы или разрядностью рабочих серверов.
При запуске на одном узле нескольких экземпляров сервера 1С:Предприятие при получении лицензии из сервиса лицензирования вам потребуется отдельная лицензия на каждый запущенный экземпляр.
При этом на сервисе лицензирования также потребуется установить и запустить на разных портах несколько экземпляров сервера 1С.
При работе терминального сервера лицензия будет выдаваться не на терминальный сеанс, допускающий неограниченное число сеансов 1С:Предприятие, а на каждый сеанс 1С.
Как видим, особенностей у сервиса лицензирования хватает и подходить к его развертыванию следует взвешенно, проанализировав все плюсы и минусы относительно собственной ситуации.
Так, например, в однозначные плюсы можно записать возможность изменять параметры компьютера или виртуальной машины сервера 1С без необходимости повторной активации лицензии.
А в столь же однозначные минусы то, что теперь два экземпляра сервера на одном узле потребуют две серверных лицензии вместо одной.
Что касается клиентских лицензий, то здесь ситуация не меняется, за исключением терминального сервера.
Но есть и плюс, при наличии нескольких серверов в кластере они могут использовать для выдачи клиентам общий пул лицензий, что исключает ситуации, когда на сервере А лицензии закончились, а на сервере Б их еще с избытком.
Ну и не забываем о том, что наличие сервиса лицензирования совсем не означает необходимости переноса всех лицензий на него. Вы можете перенести только те лицензии, которые считаете нужным, а другие оставить непосредственно на серверах.
Если сильно упростить ситуацию, то поиск лицензии будет происходить следующим образом: сначала на клиенте, потом на сервере, потом на сервисе лицензирования.
В заключение хочется сказать, что сервис лицензирования достаточно удобная штука, но со своими особенностями и перед его использованием следует хорошо все продумать, чтобы не оказалось, что при эксплуатации минусы вдруг перевесят плюсы.
В обсуждениях многие упоминали и планировали развертывание сервера лицензирования 1С, поэтому мы решили отдельным материалом осветить все достоинства и недостатки такого решения.
Начнем с того, что правильно такое решение называется именно Сервис лицензирования, а не Сервер лицензирования, но второй вариант давно прижился и его также можно использовать, только следует понимать, что речь идет об одном и том же.
Сервис лицензирования представляет отдельную серверную инсталляцию в кластере серверов, которая содержит только одноименную службу (Назначение функциональности в терминах 1С) и не требует для запуска отдельной серверной лицензии.
Сервис лицензирования может выдавать серверные и клиентские многопользовательские лицензии, последние всегда выдаются только на сеанс, вне зависимости от режима подключения клиента.
Минимальные требования к сервису лицензирования – два ядра и 4 ГБ оперативной памяти, хотя последнее требование на наш взгляд несколько завышено.
Также следует помнить, что сервис лицензирования не работает с HASP-ключами и не может привязать лицензию к такому ключу.
Еще один важный момент – сервис лицензирования не работает с клиентскими подключениями, а выдает лицензии только серверу (серверам), который в свою очередь может выдать ее клиенту.
Версия платформы и разрядность сервиса лицензирования должна совпадать с версией платформы или разрядностью рабочих серверов.
При запуске на одном узле нескольких экземпляров сервера 1С:Предприятие при получении лицензии из сервиса лицензирования вам потребуется отдельная лицензия на каждый запущенный экземпляр.
При этом на сервисе лицензирования также потребуется установить и запустить на разных портах несколько экземпляров сервера 1С.
При работе терминального сервера лицензия будет выдаваться не на терминальный сеанс, допускающий неограниченное число сеансов 1С:Предприятие, а на каждый сеанс 1С.
Как видим, особенностей у сервиса лицензирования хватает и подходить к его развертыванию следует взвешенно, проанализировав все плюсы и минусы относительно собственной ситуации.
Так, например, в однозначные плюсы можно записать возможность изменять параметры компьютера или виртуальной машины сервера 1С без необходимости повторной активации лицензии.
А в столь же однозначные минусы то, что теперь два экземпляра сервера на одном узле потребуют две серверных лицензии вместо одной.
Что касается клиентских лицензий, то здесь ситуация не меняется, за исключением терминального сервера.
Но есть и плюс, при наличии нескольких серверов в кластере они могут использовать для выдачи клиентам общий пул лицензий, что исключает ситуации, когда на сервере А лицензии закончились, а на сервере Б их еще с избытком.
Ну и не забываем о том, что наличие сервиса лицензирования совсем не означает необходимости переноса всех лицензий на него. Вы можете перенести только те лицензии, которые считаете нужным, а другие оставить непосредственно на серверах.
Если сильно упростить ситуацию, то поиск лицензии будет происходить следующим образом: сначала на клиенте, потом на сервере, потом на сервисе лицензирования.
В заключение хочется сказать, что сервис лицензирования достаточно удобная штука, но со своими особенностями и перед его использованием следует хорошо все продумать, чтобы не оказалось, что при эксплуатации минусы вдруг перевесят плюсы.
👍20❤2🥱1
Как мы пишем код с ИИ и чем это отличается от написания кода руками
Вопрос привлечения ИИ к выполнению повседневных задач волнует многих коллег, но вместе с тем есть превратное представление, что если специалист использует ИИ, то специалист он так себе, а то. что выдала ИИ – что-то низкопробное, не совсем качественное. То ли дело руками.
Поэтому мы решили рассказать, как писали последний скрипт, который опубликовали вчера, какую роль там сыграла нейросеть и как вообще изменился процесс разработки.
Разработка, несомненно, процесс творческий, но само написание кода – это еще та рутина. Потому как кроме основной логики вам приходится писать обертки, проверки, сервисные функции и т.д. и т.п. что долго, нудно и вообще претит творческому духу.
И это когда вы знаете язык на уровне, что команды сами от пальцев отлетают, а если вы пишете на языке время от времени, то постоянно будете спотыкаться о синтаксис, конструкции, допускать простые ошибки, забывать приводить типы и т.д и т.п.
В общем, вроде бы и понятно, что делать, но постоянно какие-то сложности. А время идет. Кроме того, еще и отладить надо, проверив разные режимы работы и выяснив почему только что все работало, а тут, неожиданно сломалось.
По кратким прикидкам работа с данным скриптом заняла бы не менее полного рабочего дня. Но был бы это принципиально иной результат, более качественный? Несомненно, все так, только есть тонкость, как в старом анекдоте: не в лотерею, а в карты, не Волгу, а три рубля, не выиграл, а проиграл.
ИИ сейчас уже пишет код гораздо более качественно, чем человек. Вы можете открыть скрипт и посмотреть, он написан по всем правилам PowerShell, с правильным форматированием и синтаксисом, что обеспечивает ему отличную читабельность.
Он прокомментирован и поэтому если вы даже неуверенно читаете сам код, то без труда поймете общую структуру.
Он документирован, прямо в самом начале написано, что это за скрипт, что делает, как его запускать и подключать. Для чего нужны какие файлы и т.д. и т.п. Также документированы все файлы настроек , в которых написано, для чего они нужны и как их заполнять.
И именно это обычно является слабым местом программиста человека, редко кто удосуживается писать подробные комментарии и краткую документацию прямо в коде. Обычно это оставляют «на потом», что обозначает чаще всего «никогда».
Также весь скрипт обернут проверками практически везде, с понятными сообщениями пользователю, если что-то пошло не так или чего-то не хватает. Нет нужной зависимости – напишем, не нашли конфигурационных файлов – тоже, максимально понятно русским языком, да еще и в лог занесем.
Это тоже слабое место программиста человека, потому как тоже долго, нудно, муторно. Проще предположить, что все нужное есть, а если нет – невелика беда, ну выкинет скрипт ошибку, делов то.
Надо ли говорить, что такой подход полностью порочен и не добавляет программисту очков в глазах пользователя, у которого вчера работало. а сегодня полотно каких-то заморских ругательств пишет.
А особенно порадуются ваши коллеги, которые будут это все эксплуатировать и, скажем, при переносе на новую систему будут долго пытаться понять, что происходит, вместо того чтобы получить понятное сообщение об отсутствии какой-то зависимости.
ИИ все это делает сразу и не напрягаясь, ее даже не нужно об этом просить, для нее это стиль разработки по умолчанию.
Плюс меняется сам процесс, теперь вы сосредоточены именно на творческой части процесса и занимаетесь именно тем, чем и хотели – разработкой и отладкой, а рутину в виде написания кода буквами берет на себя ИИ.
В нашем случае ИИ накосячил только в одном месте – формировании строки подключения к ibcmd и это было единственное место, где мы просто молча поправили руками и сказали сетке – правильно вот так, прими к сведению.
Но там вопрос тонкий, ошибся он на том, что очень скупо освещено в официальной документации и курсе только те, кто в курсе.
Ну и результат мы получили всего часа за полтора, большую часть времени посвятив отладке и проверке при различных вводных.
Вопрос привлечения ИИ к выполнению повседневных задач волнует многих коллег, но вместе с тем есть превратное представление, что если специалист использует ИИ, то специалист он так себе, а то. что выдала ИИ – что-то низкопробное, не совсем качественное. То ли дело руками.
Поэтому мы решили рассказать, как писали последний скрипт, который опубликовали вчера, какую роль там сыграла нейросеть и как вообще изменился процесс разработки.
Разработка, несомненно, процесс творческий, но само написание кода – это еще та рутина. Потому как кроме основной логики вам приходится писать обертки, проверки, сервисные функции и т.д. и т.п. что долго, нудно и вообще претит творческому духу.
И это когда вы знаете язык на уровне, что команды сами от пальцев отлетают, а если вы пишете на языке время от времени, то постоянно будете спотыкаться о синтаксис, конструкции, допускать простые ошибки, забывать приводить типы и т.д и т.п.
В общем, вроде бы и понятно, что делать, но постоянно какие-то сложности. А время идет. Кроме того, еще и отладить надо, проверив разные режимы работы и выяснив почему только что все работало, а тут, неожиданно сломалось.
По кратким прикидкам работа с данным скриптом заняла бы не менее полного рабочего дня. Но был бы это принципиально иной результат, более качественный? Несомненно, все так, только есть тонкость, как в старом анекдоте: не в лотерею, а в карты, не Волгу, а три рубля, не выиграл, а проиграл.
ИИ сейчас уже пишет код гораздо более качественно, чем человек. Вы можете открыть скрипт и посмотреть, он написан по всем правилам PowerShell, с правильным форматированием и синтаксисом, что обеспечивает ему отличную читабельность.
Он прокомментирован и поэтому если вы даже неуверенно читаете сам код, то без труда поймете общую структуру.
Он документирован, прямо в самом начале написано, что это за скрипт, что делает, как его запускать и подключать. Для чего нужны какие файлы и т.д. и т.п. Также документированы все файлы настроек , в которых написано, для чего они нужны и как их заполнять.
И именно это обычно является слабым местом программиста человека, редко кто удосуживается писать подробные комментарии и краткую документацию прямо в коде. Обычно это оставляют «на потом», что обозначает чаще всего «никогда».
Также весь скрипт обернут проверками практически везде, с понятными сообщениями пользователю, если что-то пошло не так или чего-то не хватает. Нет нужной зависимости – напишем, не нашли конфигурационных файлов – тоже, максимально понятно русским языком, да еще и в лог занесем.
Это тоже слабое место программиста человека, потому как тоже долго, нудно, муторно. Проще предположить, что все нужное есть, а если нет – невелика беда, ну выкинет скрипт ошибку, делов то.
Надо ли говорить, что такой подход полностью порочен и не добавляет программисту очков в глазах пользователя, у которого вчера работало. а сегодня полотно каких-то заморских ругательств пишет.
А особенно порадуются ваши коллеги, которые будут это все эксплуатировать и, скажем, при переносе на новую систему будут долго пытаться понять, что происходит, вместо того чтобы получить понятное сообщение об отсутствии какой-то зависимости.
ИИ все это делает сразу и не напрягаясь, ее даже не нужно об этом просить, для нее это стиль разработки по умолчанию.
Плюс меняется сам процесс, теперь вы сосредоточены именно на творческой части процесса и занимаетесь именно тем, чем и хотели – разработкой и отладкой, а рутину в виде написания кода буквами берет на себя ИИ.
В нашем случае ИИ накосячил только в одном месте – формировании строки подключения к ibcmd и это было единственное место, где мы просто молча поправили руками и сказали сетке – правильно вот так, прими к сведению.
Но там вопрос тонкий, ошибся он на том, что очень скупо освещено в официальной документации и курсе только те, кто в курсе.
Ну и результат мы получили всего часа за полтора, большую часть времени посвятив отладке и проверке при различных вводных.
👍27🔥5💯2❤1⚡1
Как читать таблицу маршрутизации в Windows
Как показывает практика, маршрутизация - одна из наиболее сложных тем для начинающих администраторов. Хотя, казалось бы, берем таблицу маршрутов, там все написано.
Но не все умеют правильно читать и понимать там написанное.
Следует запомнить несколько простых правил.
1️⃣ Сначала в таблице ищется маршрут с самой узкой маской. Минимальная маска - 255.255.255.255, максимальная - 0.0.0.0.
2️⃣ Если маршрутов несколько, то берется маршрут с самой маленькой метрикой.
3️⃣ После того, как маршрут найден, следует определить интерфейс выхода, который должен быть расположен в одной из непосредственно присоединенных сетей, т.е. быть доступен на канальном уровне.
Посмотрим на картинку внизу. Если мы хотим пропинговать сами себя, т.е. 192.168.233.154, то для этого сразу будет найден кратчайший маршрут в непосредственно присоединенной сети (зеленый). On-link обозначает непосредственно присоединенную сеть.
Если мы хотим обратиться к ПК из своего сегмента. то нам подойдет маршрут с более широкой маской /24 (желтый).
А если ни одного подходящего маршрута нет? Тогда нам следует использовать маршрут по умолчанию или нулевой маршрут 0.0.0.0/0.
Смотрим, таких маршрутов сразу два. Какой из них использовать? Тот у кого меньше метрика, т.е. на интерфейса 10.20.0.101 Он тоже доступен без маршрутизации.
Если же этого маршрута не будет (отключим VPN), то заработает верхний маршрут с метрикой 25. Но там стоит адрес шлюза - 192.168.233.2. Поэтому идем дальше и ищем маршрут уже для этого адреса.
Поиск такого маршрута производится только среди непосредственно присоединенных сетей и очень скоро мы снова находим нужный маршрут, который помечен желтым.
☝️ Поэтому всегда, составляя и анализируя маршруты, помним - любой маршрут должен приводить в непосредственно присоединенную сеть, иначе он работать не будет.
Почему? Да потому что IP - это 3-й уровень модели OSI - сетевой и нельзя просто так передавать IP-пакеты между ПК. Для того, чтобы это сделать, мы должны опуститься на канальный уровень и вложить их в датафреймы.
А потом еще ниже, на физический, но так глубоко мы копать не будем.
А канальный уровень - это непосредственно присоединенная сеть и только так. Это же ответ на многие вопросы типа: я написал маршрут, а он не работает. В этом случае всегда смотрим, а можем ли мы по нему достичь непосредственно присоединенной сети или нет.
Как показывает практика, маршрутизация - одна из наиболее сложных тем для начинающих администраторов. Хотя, казалось бы, берем таблицу маршрутов, там все написано.
Но не все умеют правильно читать и понимать там написанное.
Следует запомнить несколько простых правил.
1️⃣ Сначала в таблице ищется маршрут с самой узкой маской. Минимальная маска - 255.255.255.255, максимальная - 0.0.0.0.
2️⃣ Если маршрутов несколько, то берется маршрут с самой маленькой метрикой.
3️⃣ После того, как маршрут найден, следует определить интерфейс выхода, который должен быть расположен в одной из непосредственно присоединенных сетей, т.е. быть доступен на канальном уровне.
Посмотрим на картинку внизу. Если мы хотим пропинговать сами себя, т.е. 192.168.233.154, то для этого сразу будет найден кратчайший маршрут в непосредственно присоединенной сети (зеленый). On-link обозначает непосредственно присоединенную сеть.
Если мы хотим обратиться к ПК из своего сегмента. то нам подойдет маршрут с более широкой маской /24 (желтый).
А если ни одного подходящего маршрута нет? Тогда нам следует использовать маршрут по умолчанию или нулевой маршрут 0.0.0.0/0.
Смотрим, таких маршрутов сразу два. Какой из них использовать? Тот у кого меньше метрика, т.е. на интерфейса 10.20.0.101 Он тоже доступен без маршрутизации.
Если же этого маршрута не будет (отключим VPN), то заработает верхний маршрут с метрикой 25. Но там стоит адрес шлюза - 192.168.233.2. Поэтому идем дальше и ищем маршрут уже для этого адреса.
Поиск такого маршрута производится только среди непосредственно присоединенных сетей и очень скоро мы снова находим нужный маршрут, который помечен желтым.
☝️ Поэтому всегда, составляя и анализируя маршруты, помним - любой маршрут должен приводить в непосредственно присоединенную сеть, иначе он работать не будет.
Почему? Да потому что IP - это 3-й уровень модели OSI - сетевой и нельзя просто так передавать IP-пакеты между ПК. Для того, чтобы это сделать, мы должны опуститься на канальный уровень и вложить их в датафреймы.
А потом еще ниже, на физический, но так глубоко мы копать не будем.
А канальный уровень - это непосредственно присоединенная сеть и только так. Это же ответ на многие вопросы типа: я написал маршрут, а он не работает. В этом случае всегда смотрим, а можем ли мы по нему достичь непосредственно присоединенной сети или нет.
1👍33❤4
О жизни, о молодежи
Молодежь нынче принято ругать, мол не такие, такие-сякие, вот мы в их годы… Явление это не новое и тянется с поколения в поколение. Особенно на сломе технологических укладов. Проблему отцов и детей поднимали еще древние философы, не говоря о классиках русской литературы.
И вот сегодня произошел интересный случай, который заставил меня совсем по-другому посмотреть на нашу молодежь. Дело было вечером, я собирался выйти пройтись по магазинам, так как закончилось кофе и так, по мелочи к завтраку.
Уже собираясь выходить, зашел на кухню и услышал из открытого окна поток отборного мата откуда-то из-под подъезда. Голос незнакомый, всех местных «буйных» после третьего стакана я знаю. Матерился он не на кого-то конкретно, а просто так, в темноту.
А у нас, в Белгороде, уличное освещение отсутствует как класс еще с осени, после первых прилетов по энергетике. И тут из темноты, со стороны спортивной площадки выезжает паренек лет 13-14 и вежливо, на вы спрашивает: дедушка, а чего вы тут материтесь?
Я напрягся и приготовился быстро выбежать, если события примут неприятный оборот, мало-ли, но дед явно не ожидал такого и включил заднюю, мол это не он и вообще, чего они к нему пристали.
Постепенно со всего двора к подъезду собрались дети от младшего школьного возраста до подростков лет 15-16 и начали дружно деда стыдить.
Дед агрессии не проявлял, и я решил без спешки досмотреть все до конца. А аргументы у паренька были увесистые, но обращался он к делу предельно вежливо, на вы. Другие подтверждали, что сами слышали, как дед тут матерился.
- Ну что, вам не стыдно, тут же дети? А у вас самого внуки есть? Перед ними не стыдно?
Здесь я мысленно пареньку поаплодировал. Никакого хамства, хиханек-хаханек, все строго, по существу, культурно, вежливо.
- А если вас кто на телефон снимет и в интернет выложит?
При этом я отметил, что деда никто на телефон не снимал.
Когда я вышел на улицу деда уже застыдили и он спокойно сидел на лавке, а ребята снова переместились на площадку.
Дед незнакомый, сильно выпивший, но на алкаша не похож. Ну перебрал в выходной, бывает. Спрашивает какой это дом, какая улица. Видно, что потерялся в пространстве, а тут и до беды недалеко.
Спускаюсь с порожек, окликаю ребят, мол никто деда не знает? Никто. Ну вы, говорю, проследите за ним, хорошо…
И тут они меня снова удивили, мол не беспокойся дяденька, мы деда сфотали, в чат класса сбросили, спросили кто знает. Узнаем кто такой, проследим. Мы же не дураки, тоже все прекрасно понимаем, выпил дед лишнего.
Через полчаса я вернулся, деда не было, ребята все еще сидели на площадке, увидев меня первые доложили, мол в порядке все, его внучка в параллельном классе с какой-то из присутствующих девочек учится, пришли, забрали.
Молодежь нынче принято ругать, мол не такие, такие-сякие, вот мы в их годы… Явление это не новое и тянется с поколения в поколение. Особенно на сломе технологических укладов. Проблему отцов и детей поднимали еще древние философы, не говоря о классиках русской литературы.
И вот сегодня произошел интересный случай, который заставил меня совсем по-другому посмотреть на нашу молодежь. Дело было вечером, я собирался выйти пройтись по магазинам, так как закончилось кофе и так, по мелочи к завтраку.
Уже собираясь выходить, зашел на кухню и услышал из открытого окна поток отборного мата откуда-то из-под подъезда. Голос незнакомый, всех местных «буйных» после третьего стакана я знаю. Матерился он не на кого-то конкретно, а просто так, в темноту.
А у нас, в Белгороде, уличное освещение отсутствует как класс еще с осени, после первых прилетов по энергетике. И тут из темноты, со стороны спортивной площадки выезжает паренек лет 13-14 и вежливо, на вы спрашивает: дедушка, а чего вы тут материтесь?
Я напрягся и приготовился быстро выбежать, если события примут неприятный оборот, мало-ли, но дед явно не ожидал такого и включил заднюю, мол это не он и вообще, чего они к нему пристали.
Постепенно со всего двора к подъезду собрались дети от младшего школьного возраста до подростков лет 15-16 и начали дружно деда стыдить.
Дед агрессии не проявлял, и я решил без спешки досмотреть все до конца. А аргументы у паренька были увесистые, но обращался он к делу предельно вежливо, на вы. Другие подтверждали, что сами слышали, как дед тут матерился.
- Ну что, вам не стыдно, тут же дети? А у вас самого внуки есть? Перед ними не стыдно?
Здесь я мысленно пареньку поаплодировал. Никакого хамства, хиханек-хаханек, все строго, по существу, культурно, вежливо.
- А если вас кто на телефон снимет и в интернет выложит?
При этом я отметил, что деда никто на телефон не снимал.
Когда я вышел на улицу деда уже застыдили и он спокойно сидел на лавке, а ребята снова переместились на площадку.
Дед незнакомый, сильно выпивший, но на алкаша не похож. Ну перебрал в выходной, бывает. Спрашивает какой это дом, какая улица. Видно, что потерялся в пространстве, а тут и до беды недалеко.
Спускаюсь с порожек, окликаю ребят, мол никто деда не знает? Никто. Ну вы, говорю, проследите за ним, хорошо…
И тут они меня снова удивили, мол не беспокойся дяденька, мы деда сфотали, в чат класса сбросили, спросили кто знает. Узнаем кто такой, проследим. Мы же не дураки, тоже все прекрасно понимаем, выпил дед лишнего.
Через полчаса я вернулся, деда не было, ребята все еще сидели на площадке, увидев меня первые доложили, мол в порядке все, его внучка в параллельном классе с какой-то из присутствующих девочек учится, пришли, забрали.
👍59🔥24❤10🤮2🤡1
SMART атрибуты NVMe дисков
Если SATA SSD имели набор атрибутов SMART унаследованный от жестких дисков, многие из которых были бесполезны и не отражали реального состояния устройства, то NVMe диски получили обновленный набор атрибутов, разработанный как раз с учетом специфики устройств.
Ниже будем указывать атрибуты в форме ID Наименование RU (Наименование EN)
🔹 01 Критические предупреждения (Critical Warning) – флаг, указывающий на критические состояния накопителя, не является статическим, может изменять состояние динамически, возможные значения:
▫️
▫️
▫️
▫️
▫️
🔹 02 Температура всего устройства (Composite Temperature) – средняя температура накопителя в градусах Кельвина, для перевода в градусы Цельсия необходимо вычесть из значения 273.15. Рекомендации о порогах температур задаются именно для этого значения.
🔹 03 Доступно резервных блоков (Available Spare) – процент оставшихся резервных блоков, в норме 100 и это значение будет уменьшаться
🔹 04 Критический остаток резервных блоков (Available Spare Threshold) - при падении запаса ниже указанного значения для этого поля контроллером будет сформировано событие.
🔹 05 Процент износа (Percentage Used) - показывает процент износа устройства согласно указанного производителем ресурса, 100% обозначает полный износ, значение может превышать 100, максимальное значение 255.
🔹 06 Всего прочитано данных (Data Units Read) - количество прочитанных блоков по 512 байт, единица означает тысячу прочитанных блоков.
🔹 07 Всего записано данных (Data Units Written) - количество записанных блоков по 512 байт, единица означает тысячу записанных блоков.
🔹 08 Количество команд чтения (Host Read Commands) – количество команд чтения, выполненных контролером.
🔹 09 Количество команд записи (Host Write Commands) – количество команд записи, выполненных контроллером
🔹 10 Время занятости контроллера (Controller Busy Time) – время, которое контроллер обрабатывал команды ввода-вывода или когда в очереди находились запросы. Значение представлены в минутах.
🔹 11 Количество включений питания (Power Cycles) – счетчик включений накопителя
🔹 12 Количество отработанных часов (Power On Hours) – общее время работы накопителя в часах, учитывается также время нахождения в режимах энергосбережения
🔹 13 Небезопасных выключений (Unsafe Shutdowns) – количество выключений, когда питания накопителя было отключено прежде, чем он получил от системы уведомление о выключении питания
🔹 14 Количество неисправимых ошибок (Media and Data Integrity Errors) – счетчик неисправимых ошибок ECC, вычисления контрольных сумм CRC или несоответствия LBA
🔹 15 Записей об ошибках в журнал (Number of Error Information Log Entries) – количество записей об ошибках, произведенных в журнал контроллера
🔹 16 Время работы при высокой температуре (Warning Composite Temperature Time) – время, в минутах, которое накопитель работал с превышением порога температуры
🔹 17 Время работы при критической температуре (Critical Composite Temperature Time) - время, в минутах, которое накопитель работал с превышением критического порога температуры
🔹 18 Термодатчик 1 (Temperature Sensor 1) – первый сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего контроллер.
🔹 19 Термодатчик 2 (Temperature Sensor 2) – второй сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего NAND.
Если SATA SSD имели набор атрибутов SMART унаследованный от жестких дисков, многие из которых были бесполезны и не отражали реального состояния устройства, то NVMe диски получили обновленный набор атрибутов, разработанный как раз с учетом специфики устройств.
Ниже будем указывать атрибуты в форме ID Наименование RU (Наименование EN)
🔹 01 Критические предупреждения (Critical Warning) – флаг, указывающий на критические состояния накопителя, не является статическим, может изменять состояние динамически, возможные значения:
▫️
0x01 – доступное свободное пространство упало ниже порогового значения▫️
0x02 – температура вышла за пороговые значения (как вверх, так и вниз)▫️
0x03 - надежность подсистемы NVM ухудшилась из-за значительных проблем, связанных со средой передачи данных, включая ошибки, снижающие надежность подсистемы NVM ▫️
0x04 – накопитель перешел в режим только чтения▫️
0x08 – устройство энергозависимой памяти (DRAM) вышло из строя 🔹 02 Температура всего устройства (Composite Temperature) – средняя температура накопителя в градусах Кельвина, для перевода в градусы Цельсия необходимо вычесть из значения 273.15. Рекомендации о порогах температур задаются именно для этого значения.
🔹 03 Доступно резервных блоков (Available Spare) – процент оставшихся резервных блоков, в норме 100 и это значение будет уменьшаться
🔹 04 Критический остаток резервных блоков (Available Spare Threshold) - при падении запаса ниже указанного значения для этого поля контроллером будет сформировано событие.
🔹 05 Процент износа (Percentage Used) - показывает процент износа устройства согласно указанного производителем ресурса, 100% обозначает полный износ, значение может превышать 100, максимальное значение 255.
🔹 06 Всего прочитано данных (Data Units Read) - количество прочитанных блоков по 512 байт, единица означает тысячу прочитанных блоков.
🔹 07 Всего записано данных (Data Units Written) - количество записанных блоков по 512 байт, единица означает тысячу записанных блоков.
🔹 08 Количество команд чтения (Host Read Commands) – количество команд чтения, выполненных контролером.
🔹 09 Количество команд записи (Host Write Commands) – количество команд записи, выполненных контроллером
🔹 10 Время занятости контроллера (Controller Busy Time) – время, которое контроллер обрабатывал команды ввода-вывода или когда в очереди находились запросы. Значение представлены в минутах.
🔹 11 Количество включений питания (Power Cycles) – счетчик включений накопителя
🔹 12 Количество отработанных часов (Power On Hours) – общее время работы накопителя в часах, учитывается также время нахождения в режимах энергосбережения
🔹 13 Небезопасных выключений (Unsafe Shutdowns) – количество выключений, когда питания накопителя было отключено прежде, чем он получил от системы уведомление о выключении питания
🔹 14 Количество неисправимых ошибок (Media and Data Integrity Errors) – счетчик неисправимых ошибок ECC, вычисления контрольных сумм CRC или несоответствия LBA
🔹 15 Записей об ошибках в журнал (Number of Error Information Log Entries) – количество записей об ошибках, произведенных в журнал контроллера
🔹 16 Время работы при высокой температуре (Warning Composite Temperature Time) – время, в минутах, которое накопитель работал с превышением порога температуры
🔹 17 Время работы при критической температуре (Critical Composite Temperature Time) - время, в минутах, которое накопитель работал с превышением критического порога температуры
🔹 18 Термодатчик 1 (Temperature Sensor 1) – первый сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего контроллер.
🔹 19 Термодатчик 2 (Temperature Sensor 2) – второй сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего NAND.
2👍31👌5❤3🥱1
О бедном SMART замолвите слово
Технологию SMART не пинал только ленивый. Действительно, технология, предназначенная для контроля здоровья накопителя очень часто, не дает никаких предупреждений и диск отправляется «в края вечной охоты» абсолютно здоровым.
Но так ли это? Просто у многих присутствует ожидание, что SMART заблаговременно поставит диагноз и сообщит о критическом ухудшении здоровья заранее. Однако это не совсем верно, SMART просто собирает симптомы, но не имеет никакой расширенной аналитики. Всем этим нужно заниматься пользователю.
Да, в него внесены некоторые пороговые значения, при которых он выдаст критическое предупреждение, но не более. Поэтому надеяться на SMART в этом деле не стоит, а вот контролировать его показатели стоит.
Если проводить аналогию, то SMART вызовет скорую только если у вас температура выше 40 градусов, но если она ниже, скажем 38,5, то он будет только фиксировать эту информацию в журнале никому ничего не сообщая, в то время как длительная высокая температура – это явный повод обратиться к врачу.
На глаза попалось исследование Microsoft на эту тему от 2016 года, несмотря на возраст оно не потеряло актуальности, так как технология SMART гораздо старше и принципиально в ней ничего не меняется.
Исследования выполнялись для SSD, но с определенными поправками справедливы для любого типа накопителей.
👆 Прежде всего о точности. Только 62% вышедших из строя накопителей фиксировали в SMART изменение критических параметров, 38% вышли из строя без каких-либо симптомов в SMART.
Что касается самих симптомов, то на скорый выход из строя указывают (данные на основе статистики от MS):
🔹 Reallocated (Realloc) Sector Count – количество переназначенных секторов, 80% вышедших из строя дисков с симптомами имели изменение этого показателя.
🔹 Program/Erase (P/E) fail count – ошибки программирования/стирания, встречались у 3,5% накопителей, однозначно указывает на проблемы с флеш-памятью.
🔹 CRC and Uncorrectable errors – увеличение показателя некорректируемых ошибок также является косвенным показателем ухудшения здоровья диска.
🔹 SATA downshift count – переключение интерфейса SATA на более низкие скорости – еще один симптом, указывающий на возможные проблемы с диском.
Собственный опыт показывает, что Reallocated (Realloc) Sector Count действительно является одним из критических показателей, его увеличение однозначно показывает начало процессов деградации диска. В тоже время он редко достигает критических значений по SMART, видимые глазом проблемы начинаются гораздо раньше.
Второй, по нашему опыту показатель, это CRC and Uncorrectable errors, особенно для жестких дисков, резкий рост таких ошибок также свидетельствует о возникших с накопителем проблемах.
Поэтому не стоит ждать, что SMART сам забьет тревогу, увы, но диск успеет отказать гораздо раньше, в тоже время отслеживание ключевых показателей позволит заранее обнаружить тревожные симптомы и отреагировать на них.
Технологию SMART не пинал только ленивый. Действительно, технология, предназначенная для контроля здоровья накопителя очень часто, не дает никаких предупреждений и диск отправляется «в края вечной охоты» абсолютно здоровым.
Но так ли это? Просто у многих присутствует ожидание, что SMART заблаговременно поставит диагноз и сообщит о критическом ухудшении здоровья заранее. Однако это не совсем верно, SMART просто собирает симптомы, но не имеет никакой расширенной аналитики. Всем этим нужно заниматься пользователю.
Да, в него внесены некоторые пороговые значения, при которых он выдаст критическое предупреждение, но не более. Поэтому надеяться на SMART в этом деле не стоит, а вот контролировать его показатели стоит.
Если проводить аналогию, то SMART вызовет скорую только если у вас температура выше 40 градусов, но если она ниже, скажем 38,5, то он будет только фиксировать эту информацию в журнале никому ничего не сообщая, в то время как длительная высокая температура – это явный повод обратиться к врачу.
На глаза попалось исследование Microsoft на эту тему от 2016 года, несмотря на возраст оно не потеряло актуальности, так как технология SMART гораздо старше и принципиально в ней ничего не меняется.
Исследования выполнялись для SSD, но с определенными поправками справедливы для любого типа накопителей.
👆 Прежде всего о точности. Только 62% вышедших из строя накопителей фиксировали в SMART изменение критических параметров, 38% вышли из строя без каких-либо симптомов в SMART.
Что касается самих симптомов, то на скорый выход из строя указывают (данные на основе статистики от MS):
🔹 Reallocated (Realloc) Sector Count – количество переназначенных секторов, 80% вышедших из строя дисков с симптомами имели изменение этого показателя.
🔹 Program/Erase (P/E) fail count – ошибки программирования/стирания, встречались у 3,5% накопителей, однозначно указывает на проблемы с флеш-памятью.
🔹 CRC and Uncorrectable errors – увеличение показателя некорректируемых ошибок также является косвенным показателем ухудшения здоровья диска.
🔹 SATA downshift count – переключение интерфейса SATA на более низкие скорости – еще один симптом, указывающий на возможные проблемы с диском.
Собственный опыт показывает, что Reallocated (Realloc) Sector Count действительно является одним из критических показателей, его увеличение однозначно показывает начало процессов деградации диска. В тоже время он редко достигает критических значений по SMART, видимые глазом проблемы начинаются гораздо раньше.
Второй, по нашему опыту показатель, это CRC and Uncorrectable errors, особенно для жестких дисков, резкий рост таких ошибок также свидетельствует о возникших с накопителем проблемах.
Поэтому не стоит ждать, что SMART сам забьет тревогу, увы, но диск успеет отказать гораздо раньше, в тоже время отслеживание ключевых показателей позволит заранее обнаружить тревожные симптомы и отреагировать на них.
1👍35⚡2❤1🤮1
Можно ли «поехать в лес» в наше время
Очень часто в комментариях можно услышать, что мол все, ушли те времена. Теперь все в основном в правовом поле, если только самостоятельно не искать себе приключений со стремными работодателями.
Во многом это так, времена пошли поспокойнее, но все равно никогда нельзя быть уверенным, что даже самый белый и пушистый работодатель или контрагент внезапно не вспомнит, что есть у него кое-какие связи.
История это произошла в самом начале двадцатых с братом одного из моих знакомых. Назовем его Вася. Работал Вася менеджером по закупкам в фирме по производству стройматериалов некоего Ивана Ивановича. Сами производили блоки, плитку и всякое такое, сами продавали.
Иван Иваныча я знал, на одном районе выросли. Абсолютно нормальный и вменяемый мужик, без завязок где-то там. Ни с бандитами, ни с силовиками замечен в близких отношениях не был. Зарплату платил исправно в белую, к сотрудникам относился лояльно, самодуром не был.
В общем где-то откопал Вася нового поставщика. Попробовали несколько раз – вроде нормально. Что там было точно, доподлинно неизвестно, Иваныч говорит, что Вася там получал откаты, Вася, понятное дело, все отрицал.
В общем очередную крупную закупку контрагент попросил перевести на счет некоторого ИП. В солнечный горный Дагестан. Вася убедил бухгалтера, которой сразу не понравилось назначение платежа, что все схвачено и два миллиона ушли в один конец.
В общем – попадос. Причем контрагент формально не при делах и от этого ИП сразу открестился, мол не знаем кто такие, официально мы вам ничего не писали и сотрудника такого у нас в штате нет, про кого вы говорите.
Но два миллиона – это два миллиона. И тут Иваныч вспомнил про своего друга детства и соседа снизу Сашу. Они дружили с детства, сидели за одной партой, потом Саша пошел по бандитской стезе, отсидел, остепенился и работал где-то в охране.
С Иванычем они также приятельствовали, дети ходили в одну школу, жены общались и сами они любили вместе ездить на рыбалку.
В общем пришел Иваныч со своей бедой к Саше, тот назвал стандартную таксу – 20% плюс непредвиденные расходы, если будут.
- Не кинут? – осторожно спросил Иваныч.
- Смогут – кинут, - подтвердил Саша, - но я скажу, что ты мой близкий, не кинут, не по понятиям.
На том и порешили.
Через неделю цинканули, за той фирмой стоит диаспора, мы не осилим, не та весовая категория, а закусываться за два ляма никто не будет. Поэтому давай лоха твоего нагрузим, как верблюда.
Иваныч было дал заднюю, но его успокоили, тут не девяностые, никаких утюгов, паяльников и прочего, все в рамках. Бабло, как всегда, победило зло и Иваныч согласился.
Он позвонил Васе и пояснил, что косяк его, там диаспора, поэтому долг на нем. Вася включил броню, мол я не я, бизнес, риски. Но началась у него потом совсем другая жизнь.
Нет, никто не угрожал переломать ноги, поехать в лес и т.д. Просто он начал получать с незнакомых номеров в мессенджерах фото своих детей около школы, на площадке, жены у работы, в разных местах города, родителей.
Такие же фото начали получать его родители, брат. А потом с тех же номеров приходили сообщения, что не стыдно ли ему быть должным денег, а как он своим близким в глаза смотреть будет?
Родственники получали примерно то же самое, только их спрашивали, не стыдно ли им за своего сына, брата, мужа.
Вася кинулся в полицию, там посмотрели, почитали и сказали, что никаких оснований для возбуждения дела нет, угроз нет и вообще зачем вы сюда пришли? Это полиция, между прочем, не отвлекайте, вот когда убьют, тогда и приходите.
Тут уже Иваныч понял, что перегнул палку, но авторитетные пацаны ему пояснили, что 20% уже их, если он им их отдаст, то они успокоятся, а иначе не мешай дядя.
В общем Вася с семьей резко сорвался и исчез в Белокаменной, а дела за него решал его брат, который отдал 20% + накладные расходы через Ивановича, чтобы Вася хоть мог бы выдохнуть, а потом как-то там совместно долг закрыли.
История реальная, имена, события, места изменены, но суть осталась той же.
Очень часто в комментариях можно услышать, что мол все, ушли те времена. Теперь все в основном в правовом поле, если только самостоятельно не искать себе приключений со стремными работодателями.
Во многом это так, времена пошли поспокойнее, но все равно никогда нельзя быть уверенным, что даже самый белый и пушистый работодатель или контрагент внезапно не вспомнит, что есть у него кое-какие связи.
История это произошла в самом начале двадцатых с братом одного из моих знакомых. Назовем его Вася. Работал Вася менеджером по закупкам в фирме по производству стройматериалов некоего Ивана Ивановича. Сами производили блоки, плитку и всякое такое, сами продавали.
Иван Иваныча я знал, на одном районе выросли. Абсолютно нормальный и вменяемый мужик, без завязок где-то там. Ни с бандитами, ни с силовиками замечен в близких отношениях не был. Зарплату платил исправно в белую, к сотрудникам относился лояльно, самодуром не был.
В общем где-то откопал Вася нового поставщика. Попробовали несколько раз – вроде нормально. Что там было точно, доподлинно неизвестно, Иваныч говорит, что Вася там получал откаты, Вася, понятное дело, все отрицал.
В общем очередную крупную закупку контрагент попросил перевести на счет некоторого ИП. В солнечный горный Дагестан. Вася убедил бухгалтера, которой сразу не понравилось назначение платежа, что все схвачено и два миллиона ушли в один конец.
В общем – попадос. Причем контрагент формально не при делах и от этого ИП сразу открестился, мол не знаем кто такие, официально мы вам ничего не писали и сотрудника такого у нас в штате нет, про кого вы говорите.
Но два миллиона – это два миллиона. И тут Иваныч вспомнил про своего друга детства и соседа снизу Сашу. Они дружили с детства, сидели за одной партой, потом Саша пошел по бандитской стезе, отсидел, остепенился и работал где-то в охране.
С Иванычем они также приятельствовали, дети ходили в одну школу, жены общались и сами они любили вместе ездить на рыбалку.
В общем пришел Иваныч со своей бедой к Саше, тот назвал стандартную таксу – 20% плюс непредвиденные расходы, если будут.
- Не кинут? – осторожно спросил Иваныч.
- Смогут – кинут, - подтвердил Саша, - но я скажу, что ты мой близкий, не кинут, не по понятиям.
На том и порешили.
Через неделю цинканули, за той фирмой стоит диаспора, мы не осилим, не та весовая категория, а закусываться за два ляма никто не будет. Поэтому давай лоха твоего нагрузим, как верблюда.
Иваныч было дал заднюю, но его успокоили, тут не девяностые, никаких утюгов, паяльников и прочего, все в рамках. Бабло, как всегда, победило зло и Иваныч согласился.
Он позвонил Васе и пояснил, что косяк его, там диаспора, поэтому долг на нем. Вася включил броню, мол я не я, бизнес, риски. Но началась у него потом совсем другая жизнь.
Нет, никто не угрожал переломать ноги, поехать в лес и т.д. Просто он начал получать с незнакомых номеров в мессенджерах фото своих детей около школы, на площадке, жены у работы, в разных местах города, родителей.
Такие же фото начали получать его родители, брат. А потом с тех же номеров приходили сообщения, что не стыдно ли ему быть должным денег, а как он своим близким в глаза смотреть будет?
Родственники получали примерно то же самое, только их спрашивали, не стыдно ли им за своего сына, брата, мужа.
Вася кинулся в полицию, там посмотрели, почитали и сказали, что никаких оснований для возбуждения дела нет, угроз нет и вообще зачем вы сюда пришли? Это полиция, между прочем, не отвлекайте, вот когда убьют, тогда и приходите.
Тут уже Иваныч понял, что перегнул палку, но авторитетные пацаны ему пояснили, что 20% уже их, если он им их отдаст, то они успокоятся, а иначе не мешай дядя.
В общем Вася с семьей резко сорвался и исчез в Белокаменной, а дела за него решал его брат, который отдал 20% + накладные расходы через Ивановича, чтобы Вася хоть мог бы выдохнуть, а потом как-то там совместно долг закрыли.
История реальная, имена, события, места изменены, но суть осталась той же.
😁18❤9🥱5😢3🤮3
Статья не новая, но, как показывает практика, о данной возможности знают далеко не все.
Настраиваем проброс портов в Windows при помощи командной строки и Portproxy
Необходимость проброса портов весьма часто встающая перед системным администратором задача.
Обычно для этой цели используют службы маршрутизации и удаленного доступа (RRAS), но в ряде случаев использование данного инструмента избыточно.
В тоже время немногие знают о такой службе как Portproxy, которая управляется из командной строки при помощи команд Netsh.
Тем не менее данная служба позволяет справиться с поставленной задачей проще, быстрее и удобнее, чем инструменты графического интерфейса.
✅ Читать далее
Настраиваем проброс портов в Windows при помощи командной строки и Portproxy
Необходимость проброса портов весьма часто встающая перед системным администратором задача.
Обычно для этой цели используют службы маршрутизации и удаленного доступа (RRAS), но в ряде случаев использование данного инструмента избыточно.
В тоже время немногие знают о такой службе как Portproxy, которая управляется из командной строки при помощи команд Netsh.
Тем не менее данная служба позволяет справиться с поставленной задачей проще, быстрее и удобнее, чем инструменты графического интерфейса.
✅ Читать далее
👍34
История Windows NT
Windows NT без преувеличения можно назвать ключевой системой для Microsoft, именно она и заложенные в нее технологии заложила ту основу, которую системы Windows используют сейчас.
Начиная с Windows XP закончилось деление ОС Windows на пользовательскую и профессиональную линейку и дальше пошла развиваться именно линия NT и сегодня, запуская Windows 10 или 11 мы имеем под капотом потомка той самой NT.
Вся эта история началась очень давно, в 1980 году, когда IBM готовилась к выводу на рынок IBM PC и искала для него операционную систему. Сложность дополнительно состояла в том, что все существующие на тот момент ПК были 8-битными и для 16-битного IBM PC систему еще предстояло написать.
В этот момент на сцену вышел Билл Гейтс, который пообещал недорого решить проблему IBM, для чего купил 86-DOS у компании Seattle Computer Products и перепродал лицензию IBM.
Затем, если систему продавал IBM, то она называлась PC-DOS, а если Microsoft или кто-то еще – MS-DOS.
Несмотря на то, что на момент выхода IBM PC уже вышли 16-битные версии уже существовавших ОС DOS уверенно занял рыночную нишу. Все дело было в цене, лицензия на DOS-стоила всего 40$, а CP/M – 450$ (144$ и 1613$ в нынешних ценах).
Однако дальше дела пошли не столь хорошо, ожидаемая на замену DOS операционная система Windows в версиях 1 и 2 провалилась, а выпушенная в 1987 году OS/2 оказалась тяжелой и трудно конфигурируемой, вследствие чего тоже не достигла успеха.
Понимая, что для успеха нужна новая операционная система партнеры принялись за разработку NT OS/2, которая была полностью новой системой и не базировалась ни на DOS, ни на OS/2.
Для этого Microsoft пригласила команду специалистов из DEC во главе с Девидом Катлером, который до этого разрабатывал там VAX/VMS и RSX-11M. Система изначально разрабатывалась как полностью 32-разрядная, переносимая и многопользовательская.
Сначала данный проект должен был основываться на графическом интерфейсе OS/2 и планировался к выходу как OS/2 3.0, но отношения между партерами начали портится.
IBM была недовольна открытой архитектурой IBM PC и предпринимала действия к выпуску нового поколения компьютеров PS/2 на максимально закрытой архитектуре и с использованием в качестве системы OS/2.
Но ни PS/2, ни OS/2 не имели коммерческого успеха, а в 1990 вышла в свет Windows 3.0, которая имела оглушительный рыночный успех.
В свете успехов Microsoft решила добавить в проект NT OS/2 подсистему для программной совместимости с Windows, что очень сильно не понравилось IBM, которая, наоборот, продолжала курс на максимальную закрытость и возврат контроля над всеми компонентами ПК.
В итоге в 1991 пути компаний полностью разошлись. IBM продолжило работы над OS/2, а Microsoft забрали свои наработки и выпустила в 1993 году новую ОС под именем Windows NT.
Система позиционировалась как для сетей и профессионалов, а номер первой версии был взят от рыночно успешной Windows 3.0, и новая система вышла как Windows NT 3.1
Вместе с ней увидела свет и файловая система нового поколения NTFS, а также очень многое из того, что широко применяется сейчас.
Взрывного успеха Windows NT не получила, но за год, до момента выхода NT 3.5 было продано более 300 тыс. копий по 495$ каждая (1080$ в текущих ценах).
Несмотря на наличие ресурсов и хорошие заделы по OS/2 Warp 3 компания IBM проиграла рыночную гонку с Microsoft и так и не смогла предоставить достойного конкурента Windows.
Во многом это было связано с тем, что Microsoft и лично Билл Гейтс сделали ставку на Windows и выиграли, в то время как в IBM никто не был готов взять на себя такую ответственность за проект OS/2, который продолжал оставаться еще одним из многочисленных проектов гиганта.
Вокруг этой истории до сих пор ходит масса мифов, но на самом деле Windows NT не имеет ничего общего с IBM OS/2, кроме того, что работа некоторое время велась в рамках одного проекта, это совершенно новая ОС.
Также IBM никогда не подавала к Microsoft судебных исков по поводу Windows NT.
Windows NT без преувеличения можно назвать ключевой системой для Microsoft, именно она и заложенные в нее технологии заложила ту основу, которую системы Windows используют сейчас.
Начиная с Windows XP закончилось деление ОС Windows на пользовательскую и профессиональную линейку и дальше пошла развиваться именно линия NT и сегодня, запуская Windows 10 или 11 мы имеем под капотом потомка той самой NT.
Вся эта история началась очень давно, в 1980 году, когда IBM готовилась к выводу на рынок IBM PC и искала для него операционную систему. Сложность дополнительно состояла в том, что все существующие на тот момент ПК были 8-битными и для 16-битного IBM PC систему еще предстояло написать.
В этот момент на сцену вышел Билл Гейтс, который пообещал недорого решить проблему IBM, для чего купил 86-DOS у компании Seattle Computer Products и перепродал лицензию IBM.
Затем, если систему продавал IBM, то она называлась PC-DOS, а если Microsoft или кто-то еще – MS-DOS.
Несмотря на то, что на момент выхода IBM PC уже вышли 16-битные версии уже существовавших ОС DOS уверенно занял рыночную нишу. Все дело было в цене, лицензия на DOS-стоила всего 40$, а CP/M – 450$ (144$ и 1613$ в нынешних ценах).
Однако дальше дела пошли не столь хорошо, ожидаемая на замену DOS операционная система Windows в версиях 1 и 2 провалилась, а выпушенная в 1987 году OS/2 оказалась тяжелой и трудно конфигурируемой, вследствие чего тоже не достигла успеха.
Понимая, что для успеха нужна новая операционная система партнеры принялись за разработку NT OS/2, которая была полностью новой системой и не базировалась ни на DOS, ни на OS/2.
Для этого Microsoft пригласила команду специалистов из DEC во главе с Девидом Катлером, который до этого разрабатывал там VAX/VMS и RSX-11M. Система изначально разрабатывалась как полностью 32-разрядная, переносимая и многопользовательская.
Сначала данный проект должен был основываться на графическом интерфейсе OS/2 и планировался к выходу как OS/2 3.0, но отношения между партерами начали портится.
IBM была недовольна открытой архитектурой IBM PC и предпринимала действия к выпуску нового поколения компьютеров PS/2 на максимально закрытой архитектуре и с использованием в качестве системы OS/2.
Но ни PS/2, ни OS/2 не имели коммерческого успеха, а в 1990 вышла в свет Windows 3.0, которая имела оглушительный рыночный успех.
В свете успехов Microsoft решила добавить в проект NT OS/2 подсистему для программной совместимости с Windows, что очень сильно не понравилось IBM, которая, наоборот, продолжала курс на максимальную закрытость и возврат контроля над всеми компонентами ПК.
В итоге в 1991 пути компаний полностью разошлись. IBM продолжило работы над OS/2, а Microsoft забрали свои наработки и выпустила в 1993 году новую ОС под именем Windows NT.
Система позиционировалась как для сетей и профессионалов, а номер первой версии был взят от рыночно успешной Windows 3.0, и новая система вышла как Windows NT 3.1
Вместе с ней увидела свет и файловая система нового поколения NTFS, а также очень многое из того, что широко применяется сейчас.
Взрывного успеха Windows NT не получила, но за год, до момента выхода NT 3.5 было продано более 300 тыс. копий по 495$ каждая (1080$ в текущих ценах).
Несмотря на наличие ресурсов и хорошие заделы по OS/2 Warp 3 компания IBM проиграла рыночную гонку с Microsoft и так и не смогла предоставить достойного конкурента Windows.
Во многом это было связано с тем, что Microsoft и лично Билл Гейтс сделали ставку на Windows и выиграли, в то время как в IBM никто не был готов взять на себя такую ответственность за проект OS/2, который продолжал оставаться еще одним из многочисленных проектов гиганта.
Вокруг этой истории до сих пор ходит масса мифов, но на самом деле Windows NT не имеет ничего общего с IBM OS/2, кроме того, что работа некоторое время велась в рамках одного проекта, это совершенно новая ОС.
Также IBM никогда не подавала к Microsoft судебных исков по поводу Windows NT.
👍20❤2🤮1
Сколько ОС на самом деле скрывается под наименованием Windows 10?
С выходом в 2015 году Windows 10 компания Microsoft опрометчиво заявила, что это последняя версия Windows и дальше будут только поставляться обновления по принципу «ОС как услуга».
В целом некоторое здравое зерно в этом есть, но реализация такой схемы требует внятного и четкого наименования выпусков, чтобы потребитель четко понимал, насколько свежая у него версия и не испытывал ненужных иллюзий и разочарований.
Но Microsoft полностью провалило эту задачу, вот кто сейчас быстро скажет, какой из выпусков Windows 10 новее: «Юбилейное обновление» или «Обновление для дизайнеров»? Вот то-то же… Для пользователей система остается просто Windows 10.
А это влечет за собой ряд сложностей, так как, по сути, под вывеской Windows 10 скрывается несколько версий ОС, достаточно сильно отличающихся между собой.
Первые версии Windows 10 с номерами версий 1507 (10.0.10240) и 1511 (10.0.586) не сильно отличались от публичной бета-версии и все еще были достаточно сырыми. Но видимо в компании пришли к выводу, что стабильность сборки достигла определенного порога и ее можно отправлять в релиз, а доработки можно делать и по ходу пьесы.
Вышедшая через год 1607 (10.0.14393) стала крупным шагом вперед и фактически новой версией системы, о чем говорит резко увеличившийся номер билда. На этой же сборке был основан Server 2016 и версия с длительной поддержкой 2016 LTSB.
На базе этой же платформы (Redstone) было выпущено три обновления 1703 (10.0.15063), 1709 (10.0.16299) и 1803 (10.0.17134). Несмотря на то, что формально они все относились к одной версии, в это время шло наиболее активное развитие системы, каждый выпуск нес что-то новое и чем-то отличался от предшественника.
Достаточно активно перерабатывался и совершенствовался интерфейс, наметилась окончательная тенденция к переносу всех инструментов управления из Панели управления в новое приложение Параметры.
И именно здесь началась чехарда с откровенно неудачными наименованиями выпусков. Очевидно, что Microsoft хотела сделать имена релизов запоминающимися, по примеру macOS. Получилось как всегда…
Выпуск 1607 неожиданно стал «Юбилейным обновлением», у кого юбилей – не пояснили, ходят слухи что таким образом хотели отметить первую годовщину Windows 10.
Ну это ладно, выпуск 1703 назвали «Обновлением для дизайнеров», что-либо более неудачное придумать было трудно, потому как сразу возникали вопросы: «а нужно ли мне ставить это обновление если я не дизайнер?»
Следующий выпуск 1709 стал «Осенним обновлением для дизайнеров» чем только усугубил ситуацию и «без бутылки» в версиях стало не разобраться.
При этом, несмотря на схожую модель, та же macOS позиционировала каждый выпуск как отдельную версию ОС, в Windows же придерживались термина «обновление» что только добавляло путаницы и как-бы намекало не необязательность его установки.
Очередной выпуск 1809 (10.0.17763) все еще формально являясь Redstone на деле оказался вторым крупным обновлением для Windows 10, и эта же кодовая база легла в основу Server 2019 и нового LTSC 2019. А во многих инструкциях появились оговорки: до 1809 или после 1809.
При этом система достигла определенной зрелости и количество изменений от версии к версии стало неуклонно снижаться, впервые это стало заметно с выпуском 1909 (10.0.18363) который отличался от предыдущего выпуска 1903 (10.0.18362) всего одной цифрой в версии сборки.
Последнее более-менее серьезное обновление было с выходом версии 2004 (10.0.19041) в которой «десятка» получила законченный современный облик.
Далее пошли выпуски, не несущие никаких серьезных изменений: 20H2 (10.0.19042), 21H1 (10.0.19043), 21H2 (10.0.19044) и 22H2 (10.0.19045).
Фактически еще в 2020 году развитие текущей ветки закончилось и Microsoft стало планировать очередное крупное обновление. Но видимо трезво рассудила, что еще одно крупное обновление под старой вывеской еще больше всех запутает и выпустило его под новым именем Windows 11.
С выходом в 2015 году Windows 10 компания Microsoft опрометчиво заявила, что это последняя версия Windows и дальше будут только поставляться обновления по принципу «ОС как услуга».
В целом некоторое здравое зерно в этом есть, но реализация такой схемы требует внятного и четкого наименования выпусков, чтобы потребитель четко понимал, насколько свежая у него версия и не испытывал ненужных иллюзий и разочарований.
Но Microsoft полностью провалило эту задачу, вот кто сейчас быстро скажет, какой из выпусков Windows 10 новее: «Юбилейное обновление» или «Обновление для дизайнеров»? Вот то-то же… Для пользователей система остается просто Windows 10.
А это влечет за собой ряд сложностей, так как, по сути, под вывеской Windows 10 скрывается несколько версий ОС, достаточно сильно отличающихся между собой.
Первые версии Windows 10 с номерами версий 1507 (10.0.10240) и 1511 (10.0.586) не сильно отличались от публичной бета-версии и все еще были достаточно сырыми. Но видимо в компании пришли к выводу, что стабильность сборки достигла определенного порога и ее можно отправлять в релиз, а доработки можно делать и по ходу пьесы.
Вышедшая через год 1607 (10.0.14393) стала крупным шагом вперед и фактически новой версией системы, о чем говорит резко увеличившийся номер билда. На этой же сборке был основан Server 2016 и версия с длительной поддержкой 2016 LTSB.
На базе этой же платформы (Redstone) было выпущено три обновления 1703 (10.0.15063), 1709 (10.0.16299) и 1803 (10.0.17134). Несмотря на то, что формально они все относились к одной версии, в это время шло наиболее активное развитие системы, каждый выпуск нес что-то новое и чем-то отличался от предшественника.
Достаточно активно перерабатывался и совершенствовался интерфейс, наметилась окончательная тенденция к переносу всех инструментов управления из Панели управления в новое приложение Параметры.
И именно здесь началась чехарда с откровенно неудачными наименованиями выпусков. Очевидно, что Microsoft хотела сделать имена релизов запоминающимися, по примеру macOS. Получилось как всегда…
Выпуск 1607 неожиданно стал «Юбилейным обновлением», у кого юбилей – не пояснили, ходят слухи что таким образом хотели отметить первую годовщину Windows 10.
Ну это ладно, выпуск 1703 назвали «Обновлением для дизайнеров», что-либо более неудачное придумать было трудно, потому как сразу возникали вопросы: «а нужно ли мне ставить это обновление если я не дизайнер?»
Следующий выпуск 1709 стал «Осенним обновлением для дизайнеров» чем только усугубил ситуацию и «без бутылки» в версиях стало не разобраться.
При этом, несмотря на схожую модель, та же macOS позиционировала каждый выпуск как отдельную версию ОС, в Windows же придерживались термина «обновление» что только добавляло путаницы и как-бы намекало не необязательность его установки.
Очередной выпуск 1809 (10.0.17763) все еще формально являясь Redstone на деле оказался вторым крупным обновлением для Windows 10, и эта же кодовая база легла в основу Server 2019 и нового LTSC 2019. А во многих инструкциях появились оговорки: до 1809 или после 1809.
При этом система достигла определенной зрелости и количество изменений от версии к версии стало неуклонно снижаться, впервые это стало заметно с выпуском 1909 (10.0.18363) который отличался от предыдущего выпуска 1903 (10.0.18362) всего одной цифрой в версии сборки.
Последнее более-менее серьезное обновление было с выходом версии 2004 (10.0.19041) в которой «десятка» получила законченный современный облик.
Далее пошли выпуски, не несущие никаких серьезных изменений: 20H2 (10.0.19042), 21H1 (10.0.19043), 21H2 (10.0.19044) и 22H2 (10.0.19045).
Фактически еще в 2020 году развитие текущей ветки закончилось и Microsoft стало планировать очередное крупное обновление. Но видимо трезво рассудила, что еще одно крупное обновление под старой вывеской еще больше всех запутает и выпустило его под новым именем Windows 11.
💯15❤4😢1🤮1🤡1
Взлет и падение Novell NetWare
Давным-давно осенью 1981 года группа вчерашних выпускников Дэйл Найбауэр, Дрю Мэйджер, Кайл Пауэл и Марк Хёрст основали небольшую компанию SuperSet Software, которая занималась внедрением персональных компьютеров и начала писать софт для файлового сервера на базе CP/M с процессором Motorola 68000.
Именно такие сервера продавала в их городке небольшая, основанная в 1979 году фирма Novell Джорджа Кановы.
Довольно скоро разработчики осознали, что перспективы у операционной системы CP/M нет, поэтому они решили разрабатывать собственную сетевую операционную систему.
Джордж Канова тем временем активно искал инвестиции и в 1983 году компания была преобразована в Novell, Inc., а её главой стал инвестор Рей Нурда.
Таким образом все герои нашего сегодняшнего повествования в итоге собрались под одной крышей и в этом же году выпустили операционную систему NetWare 68 для Motorola 68000, а в 1985 NetWare 86 для Intel 8086.
Для своего времени система оказалась революционной, все что вам нужно было для организации собственной сети – это купить сервер с Novell NetWare и установить на ПК программу-клиент, которая позволяла организовать плоскую сеть с общим доступом к файлам и папкам, что для 1983 года было технологическим прорывом.
Система использовала сетевой стек IPX/SPX разработки Novell, а для доступа к файлам, папкам, печати, синхронизации часов и т.д. использовался протокол NetWare Core Protocol (NCP).
При этом сетевые папки подключались на клиентские ПК как сетевые диски, но работа с ними благодаря протоколу NCP шла не на уровне блочных устройств, а именно на уровне файлов, что позволяло получать выдающуюся по тем временам производительность.
В дальнейшем в Novell отказались от поддержки Motorola 68000 и вообще выпуска собственного оборудования, а сосредоточили все усилия на сетевой операционной системе.
В 1986 году после выпуска Intel 80286 появилась NetWare 286, а в 1989 NetWare 386 для процессора Intel 80386, в дальнейшем, на фоне выпуска Windows 3.0 системы были переименованы в NetWare 2.х и NetWare 3.x соответственно.
Реальных конкурентов в то время у Netware не было, система отличалась простотой, модульностью, скоростью работы и стабильностью, один раз настроенный сервер Netware мог работать годами без вмешательства администратора.
Также Novell обеспечивала серьезное преимущество по производительности, иногда даже в соотношении от 5:1 до 10:1 с основными своими конкурентами.
Лебединой песней стал выпуск NetWare 4.x в которой впервые была представлена собственная служба каталогов NDS (домен) и произошло это в 1993 году. Началась эпоха доминирования NetWare в локальных сетях, а руководство начало почивать на лаврах, что не довело до добра.
Первый звоночек прозвучал в 1994 году с выходом Windows NT 3.5, Novell желая усложнить жизнь основному конкуренту начала затягивать выпуск клиента Novell для Windows NT в результате чего Microsoft написала собственный клиент, который оказался настолько удачным, что продолжал широко использоваться даже после выхода официального клиента.
Но время уже было упущено и было упущено не только оно, внедрение в Windows стека протоколов TCP/IP делало его универсальным клиентом для любых сетей и только увеличивала его популярность.
Разработка модуля NetWare/IP не спасло положение, как и выпуск Netware 5.x с встроенной поддержкой стека TCP/IP. Еще одной проблемой стало то, что Netware предоставлял только файловые службы и не был способен работать в качестве сервера приложений.
А былые преимущества стремительно нивелировались подросшей мощностью железа. Сказалось также и наплевательское отношение к разработчикам под Netware, что серьезно затруднило создание сторонних приложений.
Окончательную точку в истории поставил Windows NT 4.0 Terminal Server, который вышел в 1998 году и позволял сделать то, чего не умел Novell – терминальный сервер. С этого момента популярность Netware неуклонно покатилась вниз.
Последними версиями стали 6.0 (2001) и 6.5 (2003), но они уже ничего не могли изменить.
Давным-давно осенью 1981 года группа вчерашних выпускников Дэйл Найбауэр, Дрю Мэйджер, Кайл Пауэл и Марк Хёрст основали небольшую компанию SuperSet Software, которая занималась внедрением персональных компьютеров и начала писать софт для файлового сервера на базе CP/M с процессором Motorola 68000.
Именно такие сервера продавала в их городке небольшая, основанная в 1979 году фирма Novell Джорджа Кановы.
Довольно скоро разработчики осознали, что перспективы у операционной системы CP/M нет, поэтому они решили разрабатывать собственную сетевую операционную систему.
Джордж Канова тем временем активно искал инвестиции и в 1983 году компания была преобразована в Novell, Inc., а её главой стал инвестор Рей Нурда.
Таким образом все герои нашего сегодняшнего повествования в итоге собрались под одной крышей и в этом же году выпустили операционную систему NetWare 68 для Motorola 68000, а в 1985 NetWare 86 для Intel 8086.
Для своего времени система оказалась революционной, все что вам нужно было для организации собственной сети – это купить сервер с Novell NetWare и установить на ПК программу-клиент, которая позволяла организовать плоскую сеть с общим доступом к файлам и папкам, что для 1983 года было технологическим прорывом.
Система использовала сетевой стек IPX/SPX разработки Novell, а для доступа к файлам, папкам, печати, синхронизации часов и т.д. использовался протокол NetWare Core Protocol (NCP).
При этом сетевые папки подключались на клиентские ПК как сетевые диски, но работа с ними благодаря протоколу NCP шла не на уровне блочных устройств, а именно на уровне файлов, что позволяло получать выдающуюся по тем временам производительность.
В дальнейшем в Novell отказались от поддержки Motorola 68000 и вообще выпуска собственного оборудования, а сосредоточили все усилия на сетевой операционной системе.
В 1986 году после выпуска Intel 80286 появилась NetWare 286, а в 1989 NetWare 386 для процессора Intel 80386, в дальнейшем, на фоне выпуска Windows 3.0 системы были переименованы в NetWare 2.х и NetWare 3.x соответственно.
Реальных конкурентов в то время у Netware не было, система отличалась простотой, модульностью, скоростью работы и стабильностью, один раз настроенный сервер Netware мог работать годами без вмешательства администратора.
Также Novell обеспечивала серьезное преимущество по производительности, иногда даже в соотношении от 5:1 до 10:1 с основными своими конкурентами.
Лебединой песней стал выпуск NetWare 4.x в которой впервые была представлена собственная служба каталогов NDS (домен) и произошло это в 1993 году. Началась эпоха доминирования NetWare в локальных сетях, а руководство начало почивать на лаврах, что не довело до добра.
Первый звоночек прозвучал в 1994 году с выходом Windows NT 3.5, Novell желая усложнить жизнь основному конкуренту начала затягивать выпуск клиента Novell для Windows NT в результате чего Microsoft написала собственный клиент, который оказался настолько удачным, что продолжал широко использоваться даже после выхода официального клиента.
Но время уже было упущено и было упущено не только оно, внедрение в Windows стека протоколов TCP/IP делало его универсальным клиентом для любых сетей и только увеличивала его популярность.
Разработка модуля NetWare/IP не спасло положение, как и выпуск Netware 5.x с встроенной поддержкой стека TCP/IP. Еще одной проблемой стало то, что Netware предоставлял только файловые службы и не был способен работать в качестве сервера приложений.
А былые преимущества стремительно нивелировались подросшей мощностью железа. Сказалось также и наплевательское отношение к разработчикам под Netware, что серьезно затруднило создание сторонних приложений.
Окончательную точку в истории поставил Windows NT 4.0 Terminal Server, который вышел в 1998 году и позволял сделать то, чего не умел Novell – терминальный сервер. С этого момента популярность Netware неуклонно покатилась вниз.
Последними версиями стали 6.0 (2001) и 6.5 (2003), но они уже ничего не могли изменить.
👍14🫡10❤6🤮2👀1
Быстрая установка Wordpress + PHP-FPM + Caddy с кешированием Redis в Docker
Сегодня заказчик поставил вопрос – а можно ли сделать сайт на Wordpress «нормально», без постоянной свистопляски с версиями PHP и прочего. Потому как не все хостеры предоставляют VPS на свежих версиях системы, а ручное обновление PHP часто приводит к проблемам.
Можно, конечно, только придется пойти другим путем, с использованием Docker, который все свое носит с собой. И не важно какие там версии в репозиториях.
В качестве веб-сервера вместо привычного NGINX мы давно выбираем Caddy, за более простую и прозрачную работу с шифрованием, которая снимает с администратора эту головную боль.
Ну и раз мы решили все делать по-современному, то почему бы сразу не добавить объектный кеш на Redis?
В итоге получился такой файл
Там же создаем файл с переменными окружения
Файл конфигурации веб-сервера
И файл кастомных параметров PHP-FPM
Запускаем все это командой:
Ждем пока все соберется и поднимется, потом переходим по доменному имени и выполняем стандартную установку Wordpress, чтобы заработал объектный кеш – установите плагин
На этом все, мы получили быстрый и современный Wordpress, который будет всегда использовать последние версии PHP рекомендуемые разработчиками вне зависимости от вашей хостовой системы.
Сегодня заказчик поставил вопрос – а можно ли сделать сайт на Wordpress «нормально», без постоянной свистопляски с версиями PHP и прочего. Потому как не все хостеры предоставляют VPS на свежих версиях системы, а ручное обновление PHP часто приводит к проблемам.
Можно, конечно, только придется пойти другим путем, с использованием Docker, который все свое носит с собой. И не важно какие там версии в репозиториях.
В качестве веб-сервера вместо привычного NGINX мы давно выбираем Caddy, за более простую и прозрачную работу с шифрованием, которая снимает с администратора эту головную боль.
Ну и раз мы решили все делать по-современному, то почему бы сразу не добавить объектный кеш на Redis?
В итоге получился такой файл
docker-compose.yml:services:
db:
image: mariadb:10.11
container_name: wp_db
restart: always
environment:
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
MYSQL_DATABASE: ${MYSQL_DATABASE}
MYSQL_USER: ${MYSQL_USER}
MYSQL_PASSWORD: ${MYSQL_PASSWORD}
volumes:
- db_data:/var/lib/mysql
redis:
image: redis:alpine
container_name: wp_redis
restart: always
command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru
wordpress:
image: wordpress:fpm
container_name: wp_app
restart: always
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: ${MYSQL_USER}
WORDPRESS_DB_PASSWORD: ${MYSQL_PASSWORD}
WORDPRESS_DB_NAME: ${MYSQL_DATABASE}
WORDPRESS_CONFIG_EXTRA: |
define('WP_REDIS_HOST', 'redis');
volumes:
- wp_data:/var/www/html
- ./php.ini:/usr/local/etc/php/conf.d/php.ini
depends_on:
- db
- redis
caddy:
image: caddy:latest
container_name: wp_caddy
restart: always
ports:
- "80:80/tcp"
- "443:443/tcp"
- "443:443/udp"
environment:
MY_DOMAIN: ${MY_DOMAIN}
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- wp_data:/var/www/html
- caddy_data:/data
- caddy_config:/config
depends_on:
- wordpress
volumes:
db_data:
wp_data:
caddy_data:
caddy_config:
Там же создаем файл с переменными окружения
.env:MYSQL_ROOT_PASSWORD=your_secure_root_password
MYSQL_DATABASE=wordpress
MYSQL_USER=wp_user
MYSQL_PASSWORD=wp_password
MY_DOMAIN=example.com
Файл конфигурации веб-сервера
Caddyfile, если для тестирования нужен самоподписанный сертификат, то раскомментируйте опцию tls internal:{$MY_DOMAIN} {
#tls internal
root * /var/www/html
php_fastcgi wordpress:9000
file_server
# Сжатие
encode zstd gzip
# Кэширование статики (картинки, шрифты, стили, скрипты)
@static {
file
path *.ico *.css *.js *.gif *.jpg *.jpeg *.png *.svg *.woff *.woff2 *.webp
}
header @static Cache-Control "public, max-age=31536000, must-revalidate"
header {
X-Frame-Options "SAMEORIGIN"
X-Content-Type-Options "nosniff"
Referrer-Policy "strict-origin-when-cross-origin"
}
}И файл кастомных параметров PHP-FPM
php.ini, в котором мы переопределили лимиты загрузки файлов и лимит памяти.upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
Запускаем все это командой:
docker compose up -d
Ждем пока все соберется и поднимется, потом переходим по доменному имени и выполняем стандартную установку Wordpress, чтобы заработал объектный кеш – установите плагин
Redis Object Cache и активируйте его. На этом все, мы получили быстрый и современный Wordpress, который будет всегда использовать последние версии PHP рекомендуемые разработчиками вне зависимости от вашей хостовой системы.
👍23🔥6⚡1
Где лежат пределы уместности Docker
Такой интересный вопрос задали нам читатели и однозначного ответа на него нет. Потому что Docker имеет существенные отличия от классического подхода и их следует учитывать.
Но перед тем, как продолжить дальше, мы вспомним принцип бритвы Оккама, общая суть которого сводится к смыслу: не стоит множить сущности без необходимости. Это универсальное правило, для любых сфер деятельности.
Поэтому перед тем, как взять в руки любую технологию надо подумать: а что она мне даст? Какие задачи позволит решить лучше, быстрее, проще. И что вы потеряете в ее отсутствие.
Перед тем как переходить к Docker мы рассмотрим классический способ управления ПО в Linux – это пакеты. Пакеты – это надежно. Пакеты родных репозиториев непосредственно интегрированы в систему и риски что-то сломать минимальные.
Но здесь у нас появляется и другая сторона, пакеты привязаны к системе, если мейнтейнер не собрал для вашей версии ОС новую версию пакета, то у вас ее не будет. Вы можете подключить сторонний репозиторий или собрать ее сами, но это очень плохие практики в продуктовых системах, чреватые потерей стабильности и сбоями.
Классическая виртуализация ничего не меняет в этой схеме, просто позволяет разделить одну систему на несколько, каждая из которых будет выглядеть как полноценная ОС на полноценном наборе железа, со своим ядром, кастомными настройками и т.д. и т.п.
Контейнеризация на базе LXC это уже несколько иной уровень, хотя внешне такие контейнеры очень похожи на виртуальную машину, но на самом деле никакой виртуализацией тут и не пахнет.
Процессы и библиотеки LXC запускаются непосредственно на хосте и используют ядро и ресурсы хоста, просто ограничены своими пространствами имен (namespaces) и лимитами ресурсов (cgroups).
При этом LXC предоставляет контейнеризацию на уровне системы, в контейнере воспроизводится окружение любого необходимого дистрибутива Linux, доступен пакетный менеджер и большинство системных настроек.
Но ничего нового в работе с ПО у нас пока не появилось, просто теперь мы можем выбирать в разных контейнерах разные окружения, исходя их требований нашего ПО. Принципы управления и администрирования остаются классическими.
Docker же предлагает совершенно иной подход: один контейнер – один процесс. Окружение – только необходимые для работы процесса зависимости и библиотеки. А сам контейнер – сущность одноразовая, которая создается при запуске и уничтожается при остановке.
Все настройки и пользовательские данные хранятся в подключаемых томах на хосте, которые динамически монтируются в запущенный контейнер, также как и динамически создается сетевая инфраструктура.
В основе контейнера лежит атомарный образ, который собирается один раз и потом многократно используется, внесения изменений в образ «на ходу» не допускаются.
Все это достаточно непривычно и после классического подхода вызывает массу вопросов, особенно если нам нужно понимать многоконтейнерные связки. Но тут нам на помощь приходят оркестраторы, самый простой из которых Docker Compose.
Они позволяют описать конфигурацию приложения в виде кода, который расскажет какие контейнеры надо запустить, что к ним подключить, как связать между собой. Фактически переводя работу с системой на уровень «инфраструктура как код».
Теперь нам не нужно ставить пакеты, зависимости, проверять их версии, решать проблемы совместимости. Нам нужен только Docker, он сам скачает нужные образы, создаст указанные нами контейнеры, применит указанные нами настройки и все это будет работать.
Надо перенести на другую систему, легко – переносим файлы с описанием инфраструктуры и пользовательские данные. Все снова работает. Без оглядки на версию хостовой ОС. Это удобно, особенно когда приложение требует целый стек, причем определенных версий.
И требования приложения могут меняться. В этом случае просто меняем версию образа в докер и перезапускаем систему. Классическая проблема версии PHP, которой нет в дистрибутиве решается быстро и безопасно, легким движением руки.
Продолжение следует.
Такой интересный вопрос задали нам читатели и однозначного ответа на него нет. Потому что Docker имеет существенные отличия от классического подхода и их следует учитывать.
Но перед тем, как продолжить дальше, мы вспомним принцип бритвы Оккама, общая суть которого сводится к смыслу: не стоит множить сущности без необходимости. Это универсальное правило, для любых сфер деятельности.
Поэтому перед тем, как взять в руки любую технологию надо подумать: а что она мне даст? Какие задачи позволит решить лучше, быстрее, проще. И что вы потеряете в ее отсутствие.
Перед тем как переходить к Docker мы рассмотрим классический способ управления ПО в Linux – это пакеты. Пакеты – это надежно. Пакеты родных репозиториев непосредственно интегрированы в систему и риски что-то сломать минимальные.
Но здесь у нас появляется и другая сторона, пакеты привязаны к системе, если мейнтейнер не собрал для вашей версии ОС новую версию пакета, то у вас ее не будет. Вы можете подключить сторонний репозиторий или собрать ее сами, но это очень плохие практики в продуктовых системах, чреватые потерей стабильности и сбоями.
Классическая виртуализация ничего не меняет в этой схеме, просто позволяет разделить одну систему на несколько, каждая из которых будет выглядеть как полноценная ОС на полноценном наборе железа, со своим ядром, кастомными настройками и т.д. и т.п.
Контейнеризация на базе LXC это уже несколько иной уровень, хотя внешне такие контейнеры очень похожи на виртуальную машину, но на самом деле никакой виртуализацией тут и не пахнет.
Процессы и библиотеки LXC запускаются непосредственно на хосте и используют ядро и ресурсы хоста, просто ограничены своими пространствами имен (namespaces) и лимитами ресурсов (cgroups).
При этом LXC предоставляет контейнеризацию на уровне системы, в контейнере воспроизводится окружение любого необходимого дистрибутива Linux, доступен пакетный менеджер и большинство системных настроек.
Но ничего нового в работе с ПО у нас пока не появилось, просто теперь мы можем выбирать в разных контейнерах разные окружения, исходя их требований нашего ПО. Принципы управления и администрирования остаются классическими.
Docker же предлагает совершенно иной подход: один контейнер – один процесс. Окружение – только необходимые для работы процесса зависимости и библиотеки. А сам контейнер – сущность одноразовая, которая создается при запуске и уничтожается при остановке.
Все настройки и пользовательские данные хранятся в подключаемых томах на хосте, которые динамически монтируются в запущенный контейнер, также как и динамически создается сетевая инфраструктура.
В основе контейнера лежит атомарный образ, который собирается один раз и потом многократно используется, внесения изменений в образ «на ходу» не допускаются.
Все это достаточно непривычно и после классического подхода вызывает массу вопросов, особенно если нам нужно понимать многоконтейнерные связки. Но тут нам на помощь приходят оркестраторы, самый простой из которых Docker Compose.
Они позволяют описать конфигурацию приложения в виде кода, который расскажет какие контейнеры надо запустить, что к ним подключить, как связать между собой. Фактически переводя работу с системой на уровень «инфраструктура как код».
Теперь нам не нужно ставить пакеты, зависимости, проверять их версии, решать проблемы совместимости. Нам нужен только Docker, он сам скачает нужные образы, создаст указанные нами контейнеры, применит указанные нами настройки и все это будет работать.
Надо перенести на другую систему, легко – переносим файлы с описанием инфраструктуры и пользовательские данные. Все снова работает. Без оглядки на версию хостовой ОС. Это удобно, особенно когда приложение требует целый стек, причем определенных версий.
И требования приложения могут меняться. В этом случае просто меняем версию образа в докер и перезапускаем систему. Классическая проблема версии PHP, которой нет в дистрибутиве решается быстро и безопасно, легким движением руки.
Продолжение следует.
👍40❤5🔥2🤮1
Где лежат пределы уместности Docker. Продолжение
В прошлой заметке мы разобрали основные технические отличия Docker и LXC, а также подходы к управлению и администрированию. Сегодня же попытаемся понять, кому и зачем это надо. Сразу говорим, что мы не будем касаться разработки, CI/CD, а будем рассматривать его применение в продакшене.
Основная парадигма Docker: одно приложение – один контейнер. Любой сложный программный продукт – набор взаимосвязанных контейнеров, с минимальным влиянием друг на друга.
Это избавляет нас от проблем взаимозависимостей элементов стека и обеспечивает стабильную повторяемость результата при разных внешних условиях.
Если мы хотим обновить или заменить какой-то элемент стека – мы заменяем только один контейнер и не трогаем остальные, риски того, что обновление поломает весь стек – минимальны.
При классическом подходе серьезное обновление (например PHP 7 -> PHP 8) может потребовать пересборки всего стека или несет серьезные риски сломать его.
Для развернутой в Docker системы в этом нет никакой проблемы, причем такое обновление мы можем выполнить буквально на лету, качаем или собираем новый образ, уничтожаем старый контейнер, создаем и запускаем новый. Это занимает секунды. Никто и не заметит.
Это свойство одно из ключевых для технологии непрерывного развертывания. Когда ПО в продуктивной среде автоматически обновляется без крупных перерывов в обслуживании.
Но даже если у вас не стоит такой цели, то подобный подход резко позволяет снизить простой на обслуживание. А возможность представить инфраструктуру как код – упростить развертывание.
Но у всего должны быть разумные пределы и у Docker тоже, потому что в последнее время прослеживаются тенденции упаковывать в контейнеры все что нужно и все что не нужно, включая одиночные бинарники.
Следует понимать, что при всех своих плюсах Docker – это сложное ПО, еще один слой абстракции и еще одна точка отказа или человеческой ошибки.
Кроме того, Docker, как и любая технология, требует набора базовых знаний, иначе compose-файл будет для вас китайской грамоты, а первый же сбой заставит бегать по потолку.
Итак, где Docker не нужен совсем? Там, где можно поставить один-два пакета из репозитория плюс зависимости или скачать и запустить единственный бинарный файл. Юнит systemd легко пишется на коленке и никаких проблем с управлением службами сегодня нет.
Также достаточно сомнительна необходимость Docker для ПО, которое собирается и сопровождается под конкретную версию дистрибутива на всем протяжении его жизненного цикла.
В качестве примера можно привести Zabbix, да его тоже можно запустить в Docker, но смысл? Ставится двумя командами, стек поддерживается на уровне репозитория дистрибутива и никаких объективных причин его пересобирать на протяжении жизненного цикла релиза не возникнет.
Мажорное же обновление меняет схему СУБД и откат без восстановления базы из бекапа невозможен. Так что Docker тут вам ничем не поможет, если что-то пойдет не так.
Другое дело внешние приложения, тот же Wordpress, который мы получаем непосредственно от разработчика, и разработчик выставляет системные требования. Решил поднять версию PHP – садитесь и думайте, как жить дальше, скорее всего придется пересобирать весь стек.
Вот тут Docker и позволяет разделить структуру на микросервисы, каждый со своими зависимостями и управлять ими отдельно. Надо новый PHP – будет новый PHP, при этом мы никак не повлияем на соседние проекты.
Также в Docker так и просятся приложения на Python, Node JS и т.п., если вы, конечно, не хотите развести в системе бардак из библиотек разных версий и решать веселые квесты зависимостей и конфликтов между ними.
А также если вы хотите быстро и без лишних заморочек переносить такие приложения. Без оглядки на версии библиотек и доступные репозитории.
И не забываем, что Docker – это как молоток, всего лишь инструмент. Им хорошо забивать гвозди, а если нужно закручивать саморезы, то лучше взять отвертку. Будьте рассудительны и благоразумны.
В прошлой заметке мы разобрали основные технические отличия Docker и LXC, а также подходы к управлению и администрированию. Сегодня же попытаемся понять, кому и зачем это надо. Сразу говорим, что мы не будем касаться разработки, CI/CD, а будем рассматривать его применение в продакшене.
Основная парадигма Docker: одно приложение – один контейнер. Любой сложный программный продукт – набор взаимосвязанных контейнеров, с минимальным влиянием друг на друга.
Это избавляет нас от проблем взаимозависимостей элементов стека и обеспечивает стабильную повторяемость результата при разных внешних условиях.
Если мы хотим обновить или заменить какой-то элемент стека – мы заменяем только один контейнер и не трогаем остальные, риски того, что обновление поломает весь стек – минимальны.
При классическом подходе серьезное обновление (например PHP 7 -> PHP 8) может потребовать пересборки всего стека или несет серьезные риски сломать его.
Для развернутой в Docker системы в этом нет никакой проблемы, причем такое обновление мы можем выполнить буквально на лету, качаем или собираем новый образ, уничтожаем старый контейнер, создаем и запускаем новый. Это занимает секунды. Никто и не заметит.
Это свойство одно из ключевых для технологии непрерывного развертывания. Когда ПО в продуктивной среде автоматически обновляется без крупных перерывов в обслуживании.
Но даже если у вас не стоит такой цели, то подобный подход резко позволяет снизить простой на обслуживание. А возможность представить инфраструктуру как код – упростить развертывание.
Но у всего должны быть разумные пределы и у Docker тоже, потому что в последнее время прослеживаются тенденции упаковывать в контейнеры все что нужно и все что не нужно, включая одиночные бинарники.
Следует понимать, что при всех своих плюсах Docker – это сложное ПО, еще один слой абстракции и еще одна точка отказа или человеческой ошибки.
Кроме того, Docker, как и любая технология, требует набора базовых знаний, иначе compose-файл будет для вас китайской грамоты, а первый же сбой заставит бегать по потолку.
Итак, где Docker не нужен совсем? Там, где можно поставить один-два пакета из репозитория плюс зависимости или скачать и запустить единственный бинарный файл. Юнит systemd легко пишется на коленке и никаких проблем с управлением службами сегодня нет.
Также достаточно сомнительна необходимость Docker для ПО, которое собирается и сопровождается под конкретную версию дистрибутива на всем протяжении его жизненного цикла.
В качестве примера можно привести Zabbix, да его тоже можно запустить в Docker, но смысл? Ставится двумя командами, стек поддерживается на уровне репозитория дистрибутива и никаких объективных причин его пересобирать на протяжении жизненного цикла релиза не возникнет.
Мажорное же обновление меняет схему СУБД и откат без восстановления базы из бекапа невозможен. Так что Docker тут вам ничем не поможет, если что-то пойдет не так.
Другое дело внешние приложения, тот же Wordpress, который мы получаем непосредственно от разработчика, и разработчик выставляет системные требования. Решил поднять версию PHP – садитесь и думайте, как жить дальше, скорее всего придется пересобирать весь стек.
Вот тут Docker и позволяет разделить структуру на микросервисы, каждый со своими зависимостями и управлять ими отдельно. Надо новый PHP – будет новый PHP, при этом мы никак не повлияем на соседние проекты.
Также в Docker так и просятся приложения на Python, Node JS и т.п., если вы, конечно, не хотите развести в системе бардак из библиотек разных версий и решать веселые квесты зависимостей и конфликтов между ними.
А также если вы хотите быстро и без лишних заморочек переносить такие приложения. Без оглядки на версии библиотек и доступные репозитории.
И не забываем, что Docker – это как молоток, всего лишь инструмент. Им хорошо забивать гвозди, а если нужно закручивать саморезы, то лучше взять отвертку. Будьте рассудительны и благоразумны.
👍33🔥2🤮1
Явки, пароли, утюги на подоконнике
Проблема документирования, точнее недостаточного документирования – это классика жанра. Даже если документацию начинают вести, то рано или поздно на нее забивают, мол и так все помним, и так все знаем.
Но давно известно, что «тупой карандаш лучше острой памяти», потому как человек имеет свойство забывать, пропадать с радаров и, в конце концов, может даже попасть под автобус.
Сегодня обсуждали с одним заказчиком новое внедрение, ресурсы вроде бы есть, целый старый гипервизор, с него все перенесли, забирайте, переустановите, пустим в дело.
ОК, железку выключили, забрали. Хорошо, что сразу не стали ничего переустанавливать, есть у нас опыт, такая железка должна пару дней отлежаться.
И точно, уже на второй день, после обеда поступила заявка не проходит синхронизация с парой-тройкой точек. А почему не проходит? А потому что шла через этот самый узел, который выключили и вручили нам под новый проект.
Ну как так? А вот так, не записали, забыли, не помнили. Но синхронизация – это ерунда, куда хуже снести таким образом какую-нибудь БД или архив. Мало ли чего там может быть.
Другой случай, звонит коллега и спрашивает, мол ты не в курсе где у нас FTP для 1С-ки? Так ты же ее ставил, не мы. Ну так найти не могу, она в каком-то контейнере, на каком-то гипервизоре, их 11 штук, руками перебирать что ли?
Ну тут только руками. Хотя и мы сами часто инспектируя доступные ресурсы не раз и не два задавались вопросом: а что именно делает этот сервер (виртуалка, VPS) и т.д., что именно тут развернуто и могу ли я… Или лучше не надо…
На самом деле это серьезная проблема, которая нуждается в отдельном внимании. Своего рода складской учет в IT. Что где лежит, зачем и почему.
Чтобы, глядя на сервер или виртуалку вы могли быстро ответить: что именно здесь работает, с какими настройками и зачем.
Последнее тоже очень важно, так как мы неоднократно встречали сервера с которых перенесли рабочую нагрузку, но заглянув на который видели рабочие процессы и просто считали его еще одним рабочим узлом.
В идеале было бы неплохо завести документацию, хотя бы на уровне Excel: на каком физическом узле что стоит, где он физически находится, какие виртуалки подняты, какие роди выполняют.
Поменяли назначение ролей – изменили документацию. И очень хорошо, если вы ее дополните физическими схемами расположения оборудования и схемой разводки портов на патч-панели.
Иначе можно долго и увлекательно играть в квест: а давай выдернем этот патч-корд и посмотрим кто отвалится.
А еще хуже, если в разгар рабочего дня выключили или выдернули совсем не то, что предполагалось.
Как раз похожими развлечениями мы занимаемся почти месяц у одного из заказчиков, который выкупил из франшизы несколько торговых точек и теперь наводит там порядок.
По-хорошему, там надо все выбросить и сделать заново, но бизнес сейчас не в том положении, поэтому приводим в чувство то, что имеем, и постоянно документируем, документируем, документируем.
Маркируем устройства, кабели, соединения, порты. И заносим все это в таблицу, чтобы завтра можно было посреди ночи встать и сказать в какой порт коммутатора присоединен телевизор в торговом зале.
Что касается нас, то мы всю такую документацию храним в Joplin, интегрируя туда схемы их draw io, которыми можем всегда поделиться с заказчиком или просто изучить их на объекте.
А также не пренебрегаем возможностями комментировать непосредственно в самом ПО, в том же Proxmox всегда можно написать подробный комментарий к каждой виртуалке.
Что думаете по этому поводу вы? Какие подходы используете?
Проблема документирования, точнее недостаточного документирования – это классика жанра. Даже если документацию начинают вести, то рано или поздно на нее забивают, мол и так все помним, и так все знаем.
Но давно известно, что «тупой карандаш лучше острой памяти», потому как человек имеет свойство забывать, пропадать с радаров и, в конце концов, может даже попасть под автобус.
Сегодня обсуждали с одним заказчиком новое внедрение, ресурсы вроде бы есть, целый старый гипервизор, с него все перенесли, забирайте, переустановите, пустим в дело.
ОК, железку выключили, забрали. Хорошо, что сразу не стали ничего переустанавливать, есть у нас опыт, такая железка должна пару дней отлежаться.
И точно, уже на второй день, после обеда поступила заявка не проходит синхронизация с парой-тройкой точек. А почему не проходит? А потому что шла через этот самый узел, который выключили и вручили нам под новый проект.
Ну как так? А вот так, не записали, забыли, не помнили. Но синхронизация – это ерунда, куда хуже снести таким образом какую-нибудь БД или архив. Мало ли чего там может быть.
Другой случай, звонит коллега и спрашивает, мол ты не в курсе где у нас FTP для 1С-ки? Так ты же ее ставил, не мы. Ну так найти не могу, она в каком-то контейнере, на каком-то гипервизоре, их 11 штук, руками перебирать что ли?
Ну тут только руками. Хотя и мы сами часто инспектируя доступные ресурсы не раз и не два задавались вопросом: а что именно делает этот сервер (виртуалка, VPS) и т.д., что именно тут развернуто и могу ли я… Или лучше не надо…
На самом деле это серьезная проблема, которая нуждается в отдельном внимании. Своего рода складской учет в IT. Что где лежит, зачем и почему.
Чтобы, глядя на сервер или виртуалку вы могли быстро ответить: что именно здесь работает, с какими настройками и зачем.
Последнее тоже очень важно, так как мы неоднократно встречали сервера с которых перенесли рабочую нагрузку, но заглянув на который видели рабочие процессы и просто считали его еще одним рабочим узлом.
В идеале было бы неплохо завести документацию, хотя бы на уровне Excel: на каком физическом узле что стоит, где он физически находится, какие виртуалки подняты, какие роди выполняют.
Поменяли назначение ролей – изменили документацию. И очень хорошо, если вы ее дополните физическими схемами расположения оборудования и схемой разводки портов на патч-панели.
Иначе можно долго и увлекательно играть в квест: а давай выдернем этот патч-корд и посмотрим кто отвалится.
А еще хуже, если в разгар рабочего дня выключили или выдернули совсем не то, что предполагалось.
Как раз похожими развлечениями мы занимаемся почти месяц у одного из заказчиков, который выкупил из франшизы несколько торговых точек и теперь наводит там порядок.
По-хорошему, там надо все выбросить и сделать заново, но бизнес сейчас не в том положении, поэтому приводим в чувство то, что имеем, и постоянно документируем, документируем, документируем.
Маркируем устройства, кабели, соединения, порты. И заносим все это в таблицу, чтобы завтра можно было посреди ночи встать и сказать в какой порт коммутатора присоединен телевизор в торговом зале.
Что касается нас, то мы всю такую документацию храним в Joplin, интегрируя туда схемы их draw io, которыми можем всегда поделиться с заказчиком или просто изучить их на объекте.
А также не пренебрегаем возможностями комментировать непосредственно в самом ПО, в том же Proxmox всегда можно написать подробный комментарий к каждой виртуалке.
Что думаете по этому поводу вы? Какие подходы используете?
👍51❤1👏1