Их нравы
BSD- сообщество внезапно забурлило, как от пачки дрожжей сами знаете где. Хотя ничего такого мы не думали и не предполагали, да и статья давно не самая свежая.
Но это хороший индикатор отличия современного Linux от современного BSD. Linux-сообщества в основной массе давно прошли этап «элитизма» и стали обычными техническими сообществами.
Нет, не без токсичности, бывает и такое, но, в общем и целом, Linux сегодня достаточно дружелюбен к новичку. Тебя проведут куда надо, покажут что надо, помогут и направят.
Linux шел этому долго, не один год, но в общем смог избавиться от синонима «красноглазие» и стать еще одной альтернативной операционной системой.
А вот BSD от макушки до пяток поражена «элитизмом» и это видно в крайне негативной реакции на наш материал. Ну, потому что критиковать «величественный собор» нельзя, хотя нет, можно, то только причастным.
А это, как мы уже писали, прямое следствие его происхождения из академической среды, когда есть некоторые архитекторы, которые знают как надо и есть все остальные. Которые кушают то, что дают.
Любая критика воспринимается как личное оскорбление и проявление ненависти. Хотя, казалось бы, применять такие термины к сугубо техническим вопросам неуместно. Ответная реакция тоже нездоровая, пронизанная оскорблениями и снова собственным «элитизмом».
Также явно проскальзывает пренебрежение ко всем остальным, «непричастным», мол админы Proxmox, которые жмут кнопки в веб-интерфейсе – они неполноценные админы, так – нажиматели кнопок.
И все это снова и снова делает BSD крайне далекой от народа и крайне непопулярной системой. Кто-то хочет вступить в такое сообщество? Где существует пренебрежительное отношение ко всем, кто движется хоть чуть-чуть иначе «линии партии»?
Нет. И поэтому и молодежь, и профессионалы ушли в Linux, где можно спокойно обсуждать технические вопросы, не боясь случайно задеть чьи-то «религиозные» предпочтения.
А со стороны BSD-сообщества правильно было бы признать, что с их стороны нет и близко никакого аналога Proxmox, но они постараются…
Хотя это не про BSD, у них все есть, им это не нужно…
BSD- сообщество внезапно забурлило, как от пачки дрожжей сами знаете где. Хотя ничего такого мы не думали и не предполагали, да и статья давно не самая свежая.
Но это хороший индикатор отличия современного Linux от современного BSD. Linux-сообщества в основной массе давно прошли этап «элитизма» и стали обычными техническими сообществами.
Нет, не без токсичности, бывает и такое, но, в общем и целом, Linux сегодня достаточно дружелюбен к новичку. Тебя проведут куда надо, покажут что надо, помогут и направят.
Linux шел этому долго, не один год, но в общем смог избавиться от синонима «красноглазие» и стать еще одной альтернативной операционной системой.
А вот BSD от макушки до пяток поражена «элитизмом» и это видно в крайне негативной реакции на наш материал. Ну, потому что критиковать «величественный собор» нельзя, хотя нет, можно, то только причастным.
А это, как мы уже писали, прямое следствие его происхождения из академической среды, когда есть некоторые архитекторы, которые знают как надо и есть все остальные. Которые кушают то, что дают.
Любая критика воспринимается как личное оскорбление и проявление ненависти. Хотя, казалось бы, применять такие термины к сугубо техническим вопросам неуместно. Ответная реакция тоже нездоровая, пронизанная оскорблениями и снова собственным «элитизмом».
Также явно проскальзывает пренебрежение ко всем остальным, «непричастным», мол админы Proxmox, которые жмут кнопки в веб-интерфейсе – они неполноценные админы, так – нажиматели кнопок.
И все это снова и снова делает BSD крайне далекой от народа и крайне непопулярной системой. Кто-то хочет вступить в такое сообщество? Где существует пренебрежительное отношение ко всем, кто движется хоть чуть-чуть иначе «линии партии»?
Нет. И поэтому и молодежь, и профессионалы ушли в Linux, где можно спокойно обсуждать технические вопросы, не боясь случайно задеть чьи-то «религиозные» предпочтения.
А со стороны BSD-сообщества правильно было бы признать, что с их стороны нет и близко никакого аналога Proxmox, но они постараются…
Хотя это не про BSD, у них все есть, им это не нужно…
💯44😁13🤡9❤6🔥5
Docker в LXC-контейнерах Proxmox VE
Рекомендуемым разработчиками Proxmox способом запуска Docker контейнеров является виртуальная машина. Таким образом, говорят они, вы получите все преимущества от обоих платформ.
Но многим пользователям интересен запуск Docker-контейнеров в LXC, потому что LXC-контейнер не содержит прослойки виртуализации и напрямую работает с ресурсами хоста, что увеличивает производительность и уменьшает накладные расходы.
Но при этом следует понимать, что LXC-контейнеры используют ядро хоста и не могут быть мигрированы на другой узел без остановки их работы. Поэтому если вам важна живая миграция вашего Docker-окружения, то следует все-таки остановиться на виртуальных машинах.
В противном случае можно попробовать запустить Docker в LXC, для тестирования мы взяли Proxmox Virtual Environment 9.1.2 и запустили на нем LXC-контейнер с Ubuntu 24.04, при создании контейнера следует установить флаг Nesting (в последних версиях PVE установлен по умолчанию).
Далее просто устанавливаем внутри контейнера Docker по официальной инструкции.
Проверяем:
Все должно работать.
Для проверки мы решили запустить все тот же Uptime Kuma, взяли с официального сайта Compose-файл, откорректировали его под собственные требования и все сразу взлетело и заработало.
Хотя при попытке конвертации образа Uptime Kuma в LXC-контейнер, который является штатным нововведением для «нативного» запуска Docker-контейнеров в Proxmox мы получили конфликт с AppArmor.
Немного поработав с Uptime Kuma и убедившись, что все работает как надо и без ошибок мы решили реализовать задачу посложнее, например, запустить Joplin Server. Снова берем Compose-файл, корректируем, запускаем.
И снова все работает, что, собственно, и предполагалось. Проверять эту связку в «нативном» варианте мы даже не стали, так как это полностью лишено смысла и приведет только к неоправданной ручной работе по запуску и настройке, что прекрасно решается в оригинальном Docker через Compose.
Дальнейшая эксплуатация также не принесла никаких сюрпризов. Возможно в данном решении и есть какие-то подводные камни, но пока все выглядит рабочим и каких-либо затруднений не вызывает.
Поэтому можем считать эксперимент удавшимся, а способ запуска Docker в LXC на Proxmox VE вполне рабочим.
Рекомендуемым разработчиками Proxmox способом запуска Docker контейнеров является виртуальная машина. Таким образом, говорят они, вы получите все преимущества от обоих платформ.
Но многим пользователям интересен запуск Docker-контейнеров в LXC, потому что LXC-контейнер не содержит прослойки виртуализации и напрямую работает с ресурсами хоста, что увеличивает производительность и уменьшает накладные расходы.
Но при этом следует понимать, что LXC-контейнеры используют ядро хоста и не могут быть мигрированы на другой узел без остановки их работы. Поэтому если вам важна живая миграция вашего Docker-окружения, то следует все-таки остановиться на виртуальных машинах.
В противном случае можно попробовать запустить Docker в LXC, для тестирования мы взяли Proxmox Virtual Environment 9.1.2 и запустили на нем LXC-контейнер с Ubuntu 24.04, при создании контейнера следует установить флаг Nesting (в последних версиях PVE установлен по умолчанию).
Далее просто устанавливаем внутри контейнера Docker по официальной инструкции.
Проверяем:
docker run hello-world
Все должно работать.
Для проверки мы решили запустить все тот же Uptime Kuma, взяли с официального сайта Compose-файл, откорректировали его под собственные требования и все сразу взлетело и заработало.
Хотя при попытке конвертации образа Uptime Kuma в LXC-контейнер, который является штатным нововведением для «нативного» запуска Docker-контейнеров в Proxmox мы получили конфликт с AppArmor.
Немного поработав с Uptime Kuma и убедившись, что все работает как надо и без ошибок мы решили реализовать задачу посложнее, например, запустить Joplin Server. Снова берем Compose-файл, корректируем, запускаем.
И снова все работает, что, собственно, и предполагалось. Проверять эту связку в «нативном» варианте мы даже не стали, так как это полностью лишено смысла и приведет только к неоправданной ручной работе по запуску и настройке, что прекрасно решается в оригинальном Docker через Compose.
Дальнейшая эксплуатация также не принесла никаких сюрпризов. Возможно в данном решении и есть какие-то подводные камни, но пока все выглядит рабочим и каких-либо затруднений не вызывает.
Поэтому можем считать эксперимент удавшимся, а способ запуска Docker в LXC на Proxmox VE вполне рабочим.
❤6⚡1
Используете ли вы Docker в Proxmox VE (доступно несколько вариантов ответа)
Anonymous Poll
34%
Да, в виртуалках
13%
Да, в LXC
1%
Да, через конвертацию в LXC
2%
Да, прямо на хосте
4%
Нет, но собираюсь в виртуалке
4%
Нет, но собираюсь в LXC
1%
Нет, но собираюсь через "конвертацию"
19%
Нет
23%
Не использую Docker вообще
18%
Ничего не понятно, но очень интересно
🔥5
Почему PostgreSQL игнорирует мои настройки?
Время от времени сталкиваемся с таким вопросом от читателей и коллег. Обычно он возникает после того, как были изменены настройки в конфигурационном файле, но почему-то не применились.
На самом деле все просто, для конфигурационных файлов PostgreSQL действует правило – если настройка перечислена файле несколько раз, то применятся та из них, которая была прочитана последней.
Как и многие другие Linux-приложения PostgreSQL поддерживает технологию включения (include), т.е. мы может вынести настройки в отдельные конфигурационные файлы, указать к ним путь в настройках приложения, и они будут применены в том месте конфигурации, где подключаются директивой include.
В конфигурационном файле PostgreSQL она располагается в самом конце и применяется последней, что гарантирует перекрытие всех ранее указанных настроек. Сама директория с файлами include (обычно conf.d) может содержать несколько конфигурационных файлов, которые читаются в алфавитном порядке.
Но и это еще не все, многие администраторы и даже разработчики (например, PostgresPRO) практикуют выносит изменения в самый конец конфигурационного файла и на первом скриншоте как раз видна такая секция, сделанная при автоматической оптимизации версии сервера СУБД от PostgresPRO.
Такой подход имеет неоспоримые плюсы. Во-первых, ваши настройки гарантированно применятся и будут иметь приоритет над остальными. Во-вторых, все они в одном месте и вам не надо бегать по всему файлу в поисках измененных строк. И, наконец, ими легко управлять, хотите выключить – просто закомментировали этот блок, целиком или частично.
Но есть одна небольшая проблема, многие из тех, кто правят собственно конфигурационный файл редко докручивают его до самого конца и поэтому остаются в неведении о существовании альтернативного набора настроек.
Хорошо, с этим разобрались, но как узнать какие именно настройки использует сервер СУБД в текущее время? Довольно просто, достаточно выполнить команду:
Она соединится с локальным экземпляром СУБД и выполнить команду
Если же мы хотим узнать откуда именно было получено это значение, то придется пойти более сложным путем – выполнить небольшой SQL запрос, это можно сделать как в консоли, но если вы не владеете консольным кун-фу Postgres, то лучше использовать графический инструмент, скажем PgAdmin.
Данный запрос выведет не только текущее значение параметра, но и его источник, расположение файла источника и номер строки в нем.
Кстати, источником не обязательно может быть конфигурационный файл, это может быть:
▫️ default - значение по умолчанию, самый низкий приоритет
▫️ configuration file - конфигурационный файл, приоритет выше default
▫️ override - параметр изменен через ALTER SYSTEM, имеет более высокий приоритет
▫️ command line - значение командной строки при запуске, часто используется в Docker, имеет еще более высокий приоритет.
▫️ environment variable - значение из переменных окружения, которые могут быть заданы как глобально, так и на уровне отдельного клиента, приоритет еще выше.
▫️ client - установлен клиентом в рамках сессии, имеет максимальный приоритет, но применяется только в рамках текущей сессии и не влияет на остальные соединения.
Поэтому, если ваш PostgreSQL ведет себя не так как ожидается, то сначала внимательно изучите конфигурационный файл, как самый частый способ внесения изменений. А потом перейдите к более детальной отладке, чтобы точно выяснить какое значение используется в реальности и кто его установил.
Время от времени сталкиваемся с таким вопросом от читателей и коллег. Обычно он возникает после того, как были изменены настройки в конфигурационном файле, но почему-то не применились.
На самом деле все просто, для конфигурационных файлов PostgreSQL действует правило – если настройка перечислена файле несколько раз, то применятся та из них, которая была прочитана последней.
Как и многие другие Linux-приложения PostgreSQL поддерживает технологию включения (include), т.е. мы может вынести настройки в отдельные конфигурационные файлы, указать к ним путь в настройках приложения, и они будут применены в том месте конфигурации, где подключаются директивой include.
В конфигурационном файле PostgreSQL она располагается в самом конце и применяется последней, что гарантирует перекрытие всех ранее указанных настроек. Сама директория с файлами include (обычно conf.d) может содержать несколько конфигурационных файлов, которые читаются в алфавитном порядке.
Но и это еще не все, многие администраторы и даже разработчики (например, PostgresPRO) практикуют выносит изменения в самый конец конфигурационного файла и на первом скриншоте как раз видна такая секция, сделанная при автоматической оптимизации версии сервера СУБД от PostgresPRO.
Такой подход имеет неоспоримые плюсы. Во-первых, ваши настройки гарантированно применятся и будут иметь приоритет над остальными. Во-вторых, все они в одном месте и вам не надо бегать по всему файлу в поисках измененных строк. И, наконец, ими легко управлять, хотите выключить – просто закомментировали этот блок, целиком или частично.
Но есть одна небольшая проблема, многие из тех, кто правят собственно конфигурационный файл редко докручивают его до самого конца и поэтому остаются в неведении о существовании альтернативного набора настроек.
Хорошо, с этим разобрались, но как узнать какие именно настройки использует сервер СУБД в текущее время? Довольно просто, достаточно выполнить команду:
psql -U postgres -h 127.0.0.1 -d postgres -c "SHOW min_wal_size;"
Она соединится с локальным экземпляром СУБД и выполнить команду
SHOW, которая покажет используемое значение параметра конфигурации, в нашем случае min_wal_size.Если же мы хотим узнать откуда именно было получено это значение, то придется пойти более сложным путем – выполнить небольшой SQL запрос, это можно сделать как в консоли, но если вы не владеете консольным кун-фу Postgres, то лучше использовать графический инструмент, скажем PgAdmin.
SELECT name, setting, source, sourcefile, sourceline
FROM pg_settings
WHERE name = 'max_wal_size';
Данный запрос выведет не только текущее значение параметра, но и его источник, расположение файла источника и номер строки в нем.
Кстати, источником не обязательно может быть конфигурационный файл, это может быть:
▫️ default - значение по умолчанию, самый низкий приоритет
▫️ configuration file - конфигурационный файл, приоритет выше default
▫️ override - параметр изменен через ALTER SYSTEM, имеет более высокий приоритет
▫️ command line - значение командной строки при запуске, часто используется в Docker, имеет еще более высокий приоритет.
▫️ environment variable - значение из переменных окружения, которые могут быть заданы как глобально, так и на уровне отдельного клиента, приоритет еще выше.
▫️ client - установлен клиентом в рамках сессии, имеет максимальный приоритет, но применяется только в рамках текущей сессии и не влияет на остальные соединения.
Поэтому, если ваш PostgreSQL ведет себя не так как ожидается, то сначала внимательно изучите конфигурационный файл, как самый частый способ внесения изменений. А потом перейдите к более детальной отладке, чтобы точно выяснить какое значение используется в реальности и кто его установил.
👍25🔥8❤2
Как правильно рассчитать бюджет PoE
PoE – это весьма популярный стандарт подключения оконечных сетевых устройств с подачей питания непосредственно по витой паре.
И это действительно удобно, таким образом пропадает необходимость дополнительной разводки электропитания, и вы можете подключить устройство с поддержкой PoE везде, была бы витая пара.
А вот дальше начинаются сложности и неприятные неожиданности, связанные с тем, что бюджет PoE был рассчитан неправильно. Поэтому сегодня разберем все тонкости этого процесса.
Начнем с классов PoE, на сегодня их четыре:
🔹 802.3af (802.3at Type 1), PoE – до 15,4 Вт на порт
🔹 802.3at Type 2, PoE+ - до 30 Вт на порт
🔹 802.3bt Type 3, 4PPoE или PoE++ - до 60 Вт на порт
🔹 802.3bt Type 4, 4PPoE или PoE++ - до 90 Вт на порт
Для примера возьмем что-нибудь совсем простое, на чем, кстати, ошибаются гораздо чаще.
👉 Коммутатор Mercusys MS108GP
▫️ Количество портов PoE - 7
▫️ Стандарты PoE - PoE (802.3af), PoE+ (802.3at)
▫️ Бюджет PoE - 65 Вт
Теперь прикидываем, у нас есть 6 камер с максимальным потреблением 5 Вт – итого 30 Вт. Хватает бюджета? Хватает. Цена привлекательная, покупаем.
После чего мы можем сильно удивиться, когда коммутатор откажется подавать питание на 5 и 6 камеру.
Далее, обычно идут разговоры про китайцев, «китайские» ватты и прочие нелицеприятные вещи, которые не имеют к действительности никакого отношения.
На самом деле коммутатор выделяет мощность на порт не просто так и не столько, сколько попросит устройство, а строго согласно классу потребления последнего.
👉 К стандарту 802.3af относятся 4 класса потребления:
🔹 0 – мощность устройства от 0,44 до 12,95 Вт, мощность на порту 15,4 Вт
🔹 1 - мощность устройства от 0,44 до 3,84, мощность на порту 4 Вт
🔹 2 - мощность устройства от 3,84 до 6,49 Вт, мощность на порту 7 Вт
🔹3 - мощность устройства от 6,49 до 12,95 Вт, мощность на порту 15,4 Вт
👉 Стандарт 802.3at добавляет еще один класс:
🔹 4 - мощность устройства от 12,95 до 25,5 Вт, мощность на порту 30 Вт
Класс потребления устройства коммутатор определяет при его подключении, согласно току классификации. Таким образом устройство еще на этапе определения сообщает свой класс и коммутатор резервирует на порту мощность из своего бюджета согласно классу потребления устройства.
Наши камеры с 5 Вт потребления могут относится как к классу 0, так и классу 2. Если камеры окажутся класса 0, то на каждый порт коммутатор будет резервировать 15,4 Вт мощности и бюджет у нас закончится уже после 4 камеры.
Если же будет класс потребления 2, то нам повезет, на 6 устройств уйдет 42 Вт бюджета и еще запас останется.
Как узнать класс потребления устройства? Очень часто до покупки никак. Такой информации может не быть даже в спецификациях производителя. Поэтому всегда закладываемся по самому плохому варианту.
Особенно внимательно надо подходить к мощным устройствам. Скажем у нас есть уличные камеры с максимальным потреблением 15 Вт, и многие могут вполне «очевидно» рассчитывать подключить к такому коммутатору 4 подобных камеры.
Однако, если вы внимательно читали материал выше, то сразу поймете, что такие камеры – это однозначно класс 4 с резервированием 30 Вт на порт, поэтому таких камер получится подключить только две.
Поэтому внимательно изучайте спецификации и пользуйтесь при расчетах мощностью исходя из класса потребления чтобы не пришлось в очередной раз рассказывать про «китайские» ватты и обосновывать покупку дополнительных устройств.
PoE – это весьма популярный стандарт подключения оконечных сетевых устройств с подачей питания непосредственно по витой паре.
И это действительно удобно, таким образом пропадает необходимость дополнительной разводки электропитания, и вы можете подключить устройство с поддержкой PoE везде, была бы витая пара.
А вот дальше начинаются сложности и неприятные неожиданности, связанные с тем, что бюджет PoE был рассчитан неправильно. Поэтому сегодня разберем все тонкости этого процесса.
Начнем с классов PoE, на сегодня их четыре:
🔹 802.3af (802.3at Type 1), PoE – до 15,4 Вт на порт
🔹 802.3at Type 2, PoE+ - до 30 Вт на порт
🔹 802.3bt Type 3, 4PPoE или PoE++ - до 60 Вт на порт
🔹 802.3bt Type 4, 4PPoE или PoE++ - до 90 Вт на порт
Для примера возьмем что-нибудь совсем простое, на чем, кстати, ошибаются гораздо чаще.
👉 Коммутатор Mercusys MS108GP
▫️ Количество портов PoE - 7
▫️ Стандарты PoE - PoE (802.3af), PoE+ (802.3at)
▫️ Бюджет PoE - 65 Вт
Теперь прикидываем, у нас есть 6 камер с максимальным потреблением 5 Вт – итого 30 Вт. Хватает бюджета? Хватает. Цена привлекательная, покупаем.
После чего мы можем сильно удивиться, когда коммутатор откажется подавать питание на 5 и 6 камеру.
Далее, обычно идут разговоры про китайцев, «китайские» ватты и прочие нелицеприятные вещи, которые не имеют к действительности никакого отношения.
На самом деле коммутатор выделяет мощность на порт не просто так и не столько, сколько попросит устройство, а строго согласно классу потребления последнего.
👉 К стандарту 802.3af относятся 4 класса потребления:
🔹 0 – мощность устройства от 0,44 до 12,95 Вт, мощность на порту 15,4 Вт
🔹 1 - мощность устройства от 0,44 до 3,84, мощность на порту 4 Вт
🔹 2 - мощность устройства от 3,84 до 6,49 Вт, мощность на порту 7 Вт
🔹3 - мощность устройства от 6,49 до 12,95 Вт, мощность на порту 15,4 Вт
👉 Стандарт 802.3at добавляет еще один класс:
🔹 4 - мощность устройства от 12,95 до 25,5 Вт, мощность на порту 30 Вт
Класс потребления устройства коммутатор определяет при его подключении, согласно току классификации. Таким образом устройство еще на этапе определения сообщает свой класс и коммутатор резервирует на порту мощность из своего бюджета согласно классу потребления устройства.
Наши камеры с 5 Вт потребления могут относится как к классу 0, так и классу 2. Если камеры окажутся класса 0, то на каждый порт коммутатор будет резервировать 15,4 Вт мощности и бюджет у нас закончится уже после 4 камеры.
Если же будет класс потребления 2, то нам повезет, на 6 устройств уйдет 42 Вт бюджета и еще запас останется.
Как узнать класс потребления устройства? Очень часто до покупки никак. Такой информации может не быть даже в спецификациях производителя. Поэтому всегда закладываемся по самому плохому варианту.
Особенно внимательно надо подходить к мощным устройствам. Скажем у нас есть уличные камеры с максимальным потреблением 15 Вт, и многие могут вполне «очевидно» рассчитывать подключить к такому коммутатору 4 подобных камеры.
Однако, если вы внимательно читали материал выше, то сразу поймете, что такие камеры – это однозначно класс 4 с резервированием 30 Вт на порт, поэтому таких камер получится подключить только две.
Поэтому внимательно изучайте спецификации и пользуйтесь при расчетах мощностью исходя из класса потребления чтобы не пришлось в очередной раз рассказывать про «китайские» ватты и обосновывать покупку дополнительных устройств.
👍85❤4👌1🥱1
Cloud. ru – те же на манеже
Утро пятницы оказалось не добрым, прилегли рабочие виртуалки на Cloud. ru. А чего прилегли? А пес его знает, но мониторинг сработал, как внутренний, так и внешний.
Ладно, пойдем посмотрим… А, вон оно чего, оказывается все плохо и прилег целый регион AZ-1. Печально, наверное, как приличная организация, хостер оповестил своих клиентов об этом прискорбном факте, просто мы что-то пропустили…
Но увы, Cloud. ru не посчитал это нужным, подумаешь, прилегли – сущая мелочь. Тишина на сайте, тишина в телеграм-канале. Только в личном кабинете плашка, для причастных, чтобы прониклись.
На текущий момент работа сервисов частично восстановлена, что-то заработало, что-то нет. Минимальный простой составил около трех часов.
Три часа, у провайдера федерального уровня (ну так они сами себя позиционируют) и полный игнор своих клиентов. А ведь не каждый может оперативно зайти в личный кабинет и понять, что же там случилось.
Да даже если зашел, то понимания не прибавится. Что именно произошло? Надолго ли? Может пора из бекапа на резервной площадке службы раскатывать или стоит подождать.
Ну и напоследок объективный контроль этой самой виртуалки на Cloud. ru, причем это не FreeTier, это коммерческая виртуалка за деньги. Как видим инциденты там постоянно, можно даже сказать – стабильно.
Ребята, ау? Это уровень федерального провайдера? Или самохост в сельском клубе? Где мышка бежала – хвостиком вильнула или уборщица тетя Шура шваброй провода повыдергивала?
Такой «красоты» нет больше ни на одной площадке нормальных провайдеров, даже несколько ниже рангом.
В общем, почему-то мне так кажется, досидим мы тут баланс и пойдем искать другое пристанище, благо вариантов хватает.
Утро пятницы оказалось не добрым, прилегли рабочие виртуалки на Cloud. ru. А чего прилегли? А пес его знает, но мониторинг сработал, как внутренний, так и внешний.
Ладно, пойдем посмотрим… А, вон оно чего, оказывается все плохо и прилег целый регион AZ-1. Печально, наверное, как приличная организация, хостер оповестил своих клиентов об этом прискорбном факте, просто мы что-то пропустили…
Но увы, Cloud. ru не посчитал это нужным, подумаешь, прилегли – сущая мелочь. Тишина на сайте, тишина в телеграм-канале. Только в личном кабинете плашка, для причастных, чтобы прониклись.
На текущий момент работа сервисов частично восстановлена, что-то заработало, что-то нет. Минимальный простой составил около трех часов.
Три часа, у провайдера федерального уровня (ну так они сами себя позиционируют) и полный игнор своих клиентов. А ведь не каждый может оперативно зайти в личный кабинет и понять, что же там случилось.
Да даже если зашел, то понимания не прибавится. Что именно произошло? Надолго ли? Может пора из бекапа на резервной площадке службы раскатывать или стоит подождать.
Ну и напоследок объективный контроль этой самой виртуалки на Cloud. ru, причем это не FreeTier, это коммерческая виртуалка за деньги. Как видим инциденты там постоянно, можно даже сказать – стабильно.
Ребята, ау? Это уровень федерального провайдера? Или самохост в сельском клубе? Где мышка бежала – хвостиком вильнула или уборщица тетя Шура шваброй провода повыдергивала?
Такой «красоты» нет больше ни на одной площадке нормальных провайдеров, даже несколько ниже рангом.
В общем, почему-то мне так кажется, досидим мы тут баланс и пойдем искать другое пристанище, благо вариантов хватает.
💯22🔥6😁5❤2😱2
Современный подход к организации конфигурационных файлов
Прошлая заметка, про многоуровневую схему настроек в PostgreSQL вызвала ряд интересных откликов. Например, что не стоит вообще запускать службу, если в ее конфигурации дублируются опции.
Но современный подход как раз таки и подразумевает дублирование опций, возможно даже многократное.
Какого-то единого стандарта нет, но очень многие приложения допускают такое дублирование и подразумевают, что будет применено или последнее указанное значение, или параметры из внешних файлов будут иметь приоритет над основной конфигурацией.
Некоторые системы прямо подразумевают такой подход, например, systemd, которая категорически не рекомендует править вручную стандартные юниты, а предлагает воспользоваться технологией drop-in.
Аналогичную схему предлагает и Fail2ban, а так или иначе подобный подход поддерживают очень и очень многие приложения.
Если коротко, то его суть сводится к тому, что основной файл конфигурации, который поставляется вместе с пакетом, следует держать неизменным, а все изменения вносить в дополнительные файлы, которые автоматически подключаются к конфигурации.
При этом, опции, которые вы переопределили являются более приоритетными. Также многие программы допускают многократное переопределение опций. При этом в итоге применится опция с наибольшим приоритетом.
Что это дает? А это дает гибкость и удобство в управлении конфигурацией. Начнем с того, что современные системы постоянно обновляются и могут обновлять свои конфигурационные файлы.
После чего у вас есть нелегкий выбор: или оставить все как есть, или принять новый конфиг и потерять все свои настройки. Ну еще можно заморочиться и попробовать смержить конфиги вручную.
По факту обычно оставляется старый конфиг и вроде бы все хорошо. Но на самом деле не все. Ваш конфиг может происходить от какой-то там бородатой версии, которая не может, не знает и не умеет во все то, что умеет актуальный пакет.
И хорошо, если это только новые функции, а не настройки безопасности или еще что-то важное. И получается, что вы как бы и обновились, но на самом деле не до конца.
И отсюда мы приходим к тому, что стандартный конфигурационный файл пакета было бы неплохо обновлять вместе с пакетом, чтобы получать все новые настройки автоматически. А все свои изменения хранить отдельно и переопределять ими стандартные параметры.
Отдельный толчок в этом направлении дала контейнеризация и докеризация, контейнер Docker неизменяем, мы можем его убить, перезапустить, обновить на новый, и т.д. и т.п. не затрагивая пользовательские данные. За это его и любят.
Да, мы можем подкинуть конфиг снаружи, но зачем подкидывать целое полотно, если пользователю нужно изменить пять-десять строчек? И для самого пользователя это удобнее и нагляднее, потому что он видит в конфиге только то, что он изменил.
С другой стороны, иногда бывает сложно понять, а кто и где внес изменения и почему программа ведет себя «неправильно». Но большинство приложений, допускающих многоуровневые конфигурации имеют встроенные инструменты для вывода итоговой конфигурации, как минимум.
Если освоить эти механизмы, то от такого подхода мы получаем только плюсы, нам не надо больше править конфигурационные файлы, мы можем создать готовые конфиги с переопределенными опциями и просто подкидывать их на готовые системы, не заботясь об исходных файлах.
Также мы можем смело обновляться и получать новые функции, исправления и т.д. и т.п. не боясь потерять свои настройки, все ваши настройки в отдельном файле.
P.S. Алиса - художник, она так видит. Но в целом картинка в тему.
Прошлая заметка, про многоуровневую схему настроек в PostgreSQL вызвала ряд интересных откликов. Например, что не стоит вообще запускать службу, если в ее конфигурации дублируются опции.
Но современный подход как раз таки и подразумевает дублирование опций, возможно даже многократное.
Какого-то единого стандарта нет, но очень многие приложения допускают такое дублирование и подразумевают, что будет применено или последнее указанное значение, или параметры из внешних файлов будут иметь приоритет над основной конфигурацией.
Некоторые системы прямо подразумевают такой подход, например, systemd, которая категорически не рекомендует править вручную стандартные юниты, а предлагает воспользоваться технологией drop-in.
Аналогичную схему предлагает и Fail2ban, а так или иначе подобный подход поддерживают очень и очень многие приложения.
Если коротко, то его суть сводится к тому, что основной файл конфигурации, который поставляется вместе с пакетом, следует держать неизменным, а все изменения вносить в дополнительные файлы, которые автоматически подключаются к конфигурации.
При этом, опции, которые вы переопределили являются более приоритетными. Также многие программы допускают многократное переопределение опций. При этом в итоге применится опция с наибольшим приоритетом.
Что это дает? А это дает гибкость и удобство в управлении конфигурацией. Начнем с того, что современные системы постоянно обновляются и могут обновлять свои конфигурационные файлы.
После чего у вас есть нелегкий выбор: или оставить все как есть, или принять новый конфиг и потерять все свои настройки. Ну еще можно заморочиться и попробовать смержить конфиги вручную.
По факту обычно оставляется старый конфиг и вроде бы все хорошо. Но на самом деле не все. Ваш конфиг может происходить от какой-то там бородатой версии, которая не может, не знает и не умеет во все то, что умеет актуальный пакет.
И хорошо, если это только новые функции, а не настройки безопасности или еще что-то важное. И получается, что вы как бы и обновились, но на самом деле не до конца.
И отсюда мы приходим к тому, что стандартный конфигурационный файл пакета было бы неплохо обновлять вместе с пакетом, чтобы получать все новые настройки автоматически. А все свои изменения хранить отдельно и переопределять ими стандартные параметры.
Отдельный толчок в этом направлении дала контейнеризация и докеризация, контейнер Docker неизменяем, мы можем его убить, перезапустить, обновить на новый, и т.д. и т.п. не затрагивая пользовательские данные. За это его и любят.
Да, мы можем подкинуть конфиг снаружи, но зачем подкидывать целое полотно, если пользователю нужно изменить пять-десять строчек? И для самого пользователя это удобнее и нагляднее, потому что он видит в конфиге только то, что он изменил.
С другой стороны, иногда бывает сложно понять, а кто и где внес изменения и почему программа ведет себя «неправильно». Но большинство приложений, допускающих многоуровневые конфигурации имеют встроенные инструменты для вывода итоговой конфигурации, как минимум.
Если освоить эти механизмы, то от такого подхода мы получаем только плюсы, нам не надо больше править конфигурационные файлы, мы можем создать готовые конфиги с переопределенными опциями и просто подкидывать их на готовые системы, не заботясь об исходных файлах.
Также мы можем смело обновляться и получать новые функции, исправления и т.д. и т.п. не боясь потерять свои настройки, все ваши настройки в отдельном файле.
P.S. Алиса - художник, она так видит. Но в целом картинка в тему.
❤11👌8⚡2🥱2👀2
Boxes – простая настольная KVM-виртуализация
Возвращаясь к вопросу настольной виртуализации в Linux, нельзя не обратить внимание на Boxes. Это простое приложение Gnome предназначенное для работы с виртуальными машинами, в качестве гипервизора используется хорошо знакомый KVM.
Получилось быстро, просто и достаточно удобно. Почему достаточно? Потому что это Gnome-приложение, построенное в соответствии со всеми представлениями «о прекрасном» разработчиков этой системы, ну и со всеми сопутствующими прибабахами.
Но тем не менее Boxes позволяет быстро и просто создавать виртуалки. Можно использовать свой образ или виртуальный диск, либо скачать готовый. В библиотеке готовых образов представлены практически все открытые ОС: Linux (включая отечественный), BSD и даже экзотическая Haiku.
Настроек, в лучших традициях Gnome, откровенно мало. У готовой виртуалки немногим больше. Но при желании вы всегда можете внести изменения вручную в файл конфигурации виртуальной машины.
Возвращаясь к вопросу настольной виртуализации в Linux, нельзя не обратить внимание на Boxes. Это простое приложение Gnome предназначенное для работы с виртуальными машинами, в качестве гипервизора используется хорошо знакомый KVM.
Получилось быстро, просто и достаточно удобно. Почему достаточно? Потому что это Gnome-приложение, построенное в соответствии со всеми представлениями «о прекрасном» разработчиков этой системы, ну и со всеми сопутствующими прибабахами.
Но тем не менее Boxes позволяет быстро и просто создавать виртуалки. Можно использовать свой образ или виртуальный диск, либо скачать готовый. В библиотеке готовых образов представлены практически все открытые ОС: Linux (включая отечественный), BSD и даже экзотическая Haiku.
Настроек, в лучших традициях Gnome, откровенно мало. У готовой виртуалки немногим больше. Но при желании вы всегда можете внести изменения вручную в файл конфигурации виртуальной машины.
🔥7❤5👌5🥱2⚡1
Некоторые неочевидные особенности корзины Samba
Корзина Samba нравится очень многим администраторам и нам в том числе, потому что позволяет не только хранить удаленные файлы, но и сохранять их версии, что очень полезно на случай перезаписи.
Но все эти достоинства имеют и обратную сторону медали. Многие пользователи любят работать с общими файлами непосредственно в общей папке, запуская их на редактирование из сетевого расположения.
А что обычно происходит в таком случае? Правильно, система создает скрытые временные файлы, которые автоматически удаляются при окончании редактирования и надо ли говорить, что попадают они в корзину.
Несколько раз открыли один и тот же файл – получили несколько экземпляров в корзину. Таким образом, при достаточно интенсивной работе, объем корзины будет приближаться к горячему объему файлового хранилища, а то и превышать его.
И это не какая-то умозрительная ситуация, буквально на днях мы как раз разбирали этот вопрос с представителем заказчика, который был сильно удивлен почему при общем объеме шары в 35 ГБ объем резервной копии у него получался более 50 ГБ.
Поэтому корзину в Samba необходимо чистить, но делать это не в лоб, а точечно, чтобы ненароком не удалить нужное. Здесь можно опираться на расширение - .tmp или характерный формат имени временных файлов Office, которые начинаются с ~$.
Ну и выделять место для файлового сервера с корзиной нужно также оглядываясь на этот факт, а в случае использования быстрых и дорогих твердотельных накопителей имеет смысл монтировать корзину на более медленные и недорогие носители.
Корзина Samba нравится очень многим администраторам и нам в том числе, потому что позволяет не только хранить удаленные файлы, но и сохранять их версии, что очень полезно на случай перезаписи.
Но все эти достоинства имеют и обратную сторону медали. Многие пользователи любят работать с общими файлами непосредственно в общей папке, запуская их на редактирование из сетевого расположения.
А что обычно происходит в таком случае? Правильно, система создает скрытые временные файлы, которые автоматически удаляются при окончании редактирования и надо ли говорить, что попадают они в корзину.
Несколько раз открыли один и тот же файл – получили несколько экземпляров в корзину. Таким образом, при достаточно интенсивной работе, объем корзины будет приближаться к горячему объему файлового хранилища, а то и превышать его.
И это не какая-то умозрительная ситуация, буквально на днях мы как раз разбирали этот вопрос с представителем заказчика, который был сильно удивлен почему при общем объеме шары в 35 ГБ объем резервной копии у него получался более 50 ГБ.
Поэтому корзину в Samba необходимо чистить, но делать это не в лоб, а точечно, чтобы ненароком не удалить нужное. Здесь можно опираться на расширение - .tmp или характерный формат имени временных файлов Office, которые начинаются с ~$.
Ну и выделять место для файлового сервера с корзиной нужно также оглядываясь на этот факт, а в случае использования быстрых и дорогих твердотельных накопителей имеет смысл монтировать корзину на более медленные и недорогие носители.
🤔19👍4❤3👌2🍌1
Будь проще…
Сегодня маркетологи в описании товара чего только нам не предлагают, стоит только заплатить лишнюю пару-тройку, а то и десяток тысяч рублей.
Казалось бы — вот оно счастье, но эта лодка, равно как и любовная, довольно быстро разбивается о быт…
Когда-то, очень давно, на свадьбу нам подарили крутую микроволновку. С кучей программ и толстой книжкой всевозможных рецептов.
И что? Побаловаться хватило ровно на пару недель, после чего микроволновка работала в режиме: поставил тарелку – нажал кнопку – разогрел – достал.
Подобная участь постигла и крутой кухонный комбайн, купленный мною позже, работал он в основном в режиме измельчителя.
И примеров тому можно привести великое множество, но с тех пор на моей кухне живут просто микроволновки, просто измельчители и мясорубки, и просто чайники, без всякого намека на «полоумность» и не обладающие кучей ненужных функций, а просто делающие свое дело.
Это как раз перекликается с философией UNIX, каждый делает что-то одно, но делает это хорошо.
Тоже самое касается и компьютерных комплектующих. Сегодня вечером в гости напросился сын моих хороших друзей, да не просто так, а с новым компьютером, которому он уже третий день не мог дать ладу. Ну не хотел он стабильно работать и все, хоть ты тресни.
Я уже примерно предвидел что там увижу и мои ожидания полностью оправдались. «Игровая» материнская плата и «интеллектуальный» автоматический разгон в BIOS, который же был, конечно же включен.
А дальше выяснилось, что одна из планок памяти такой разгон не переваривает, со всеми вытекающими. И это не брак, потому что ее работу на такой частоте никто не обещал. А на штатной она функционирует полностью нормально.
Поэтому первый вопрос молодому товарищу был такой: «И нафига ты это купил?»
Ответ был в стиле: «Ну круто же, стильно, модно, молодежно!»
В общем сбросили настройки BIOS, отключили «полоумный» разгон. А попутно, чтобы добру не пропадать, все-таки немного разогнали память, благо память была хорошая.
После чего открыли сайт известной компьютерной сети из трех букв и сначала нашли эту «игровую» плату, а потом ровно такую-же по возможностям, но без «полоумных» функций и ЛГБТ-подсветки.
Разница в 7 тыс. рублей. Тот же чипсет, та же подсистема питания и аналогичный развод PCIe линий по разъемам (а сегодня это важно).
Молодой товарищ как-то сразу приуныл. Но тут у нас не школа благородных девиц, поэтому снова спрашиваю: «А вообще разгон тебе зачем? Ты во что-то крутое играешь?»
А сам поглядываю на RTX 3050…
«Да нет» - говорит – «в танчики иногда или в GTA»
«Тогда может CAD какой сложный или рендеринг?»
«Тоже нет…»
В общем все ясно. Круто же и выглядит красиво, мигает, сверкает и переливается. И минус 7 тыс. руб. из кармана. И плюсом пачка проблем от «полоумных» функций.
Поэтому надо быть проще, это не значит, что следует впадать в аскезу и экономить каждую копейку, отказываясь от любых улучшений. Но нужно трезво подумать надо ли это все вам и сделать выбор согласно текущих потребностей.
Я, например, давно уже не покупаю дорогие ноутбуки, потому что активно использую их несколько раз в год, в период отпусков и праздников, а остальное время он лежит на полке.
Что-то из массового сегмента работает в целом не хуже, теряет в стоимости меньше, а через года два-три его не жалко заменить на более актуальную модель.
Сегодня маркетологи в описании товара чего только нам не предлагают, стоит только заплатить лишнюю пару-тройку, а то и десяток тысяч рублей.
Казалось бы — вот оно счастье, но эта лодка, равно как и любовная, довольно быстро разбивается о быт…
Когда-то, очень давно, на свадьбу нам подарили крутую микроволновку. С кучей программ и толстой книжкой всевозможных рецептов.
И что? Побаловаться хватило ровно на пару недель, после чего микроволновка работала в режиме: поставил тарелку – нажал кнопку – разогрел – достал.
Подобная участь постигла и крутой кухонный комбайн, купленный мною позже, работал он в основном в режиме измельчителя.
И примеров тому можно привести великое множество, но с тех пор на моей кухне живут просто микроволновки, просто измельчители и мясорубки, и просто чайники, без всякого намека на «полоумность» и не обладающие кучей ненужных функций, а просто делающие свое дело.
Это как раз перекликается с философией UNIX, каждый делает что-то одно, но делает это хорошо.
Тоже самое касается и компьютерных комплектующих. Сегодня вечером в гости напросился сын моих хороших друзей, да не просто так, а с новым компьютером, которому он уже третий день не мог дать ладу. Ну не хотел он стабильно работать и все, хоть ты тресни.
Я уже примерно предвидел что там увижу и мои ожидания полностью оправдались. «Игровая» материнская плата и «интеллектуальный» автоматический разгон в BIOS, который же был, конечно же включен.
А дальше выяснилось, что одна из планок памяти такой разгон не переваривает, со всеми вытекающими. И это не брак, потому что ее работу на такой частоте никто не обещал. А на штатной она функционирует полностью нормально.
Поэтому первый вопрос молодому товарищу был такой: «И нафига ты это купил?»
Ответ был в стиле: «Ну круто же, стильно, модно, молодежно!»
В общем сбросили настройки BIOS, отключили «полоумный» разгон. А попутно, чтобы добру не пропадать, все-таки немного разогнали память, благо память была хорошая.
После чего открыли сайт известной компьютерной сети из трех букв и сначала нашли эту «игровую» плату, а потом ровно такую-же по возможностям, но без «полоумных» функций и ЛГБТ-подсветки.
Разница в 7 тыс. рублей. Тот же чипсет, та же подсистема питания и аналогичный развод PCIe линий по разъемам (а сегодня это важно).
Молодой товарищ как-то сразу приуныл. Но тут у нас не школа благородных девиц, поэтому снова спрашиваю: «А вообще разгон тебе зачем? Ты во что-то крутое играешь?»
А сам поглядываю на RTX 3050…
«Да нет» - говорит – «в танчики иногда или в GTA»
«Тогда может CAD какой сложный или рендеринг?»
«Тоже нет…»
В общем все ясно. Круто же и выглядит красиво, мигает, сверкает и переливается. И минус 7 тыс. руб. из кармана. И плюсом пачка проблем от «полоумных» функций.
Поэтому надо быть проще, это не значит, что следует впадать в аскезу и экономить каждую копейку, отказываясь от любых улучшений. Но нужно трезво подумать надо ли это все вам и сделать выбор согласно текущих потребностей.
Я, например, давно уже не покупаю дорогие ноутбуки, потому что активно использую их несколько раз в год, в период отпусков и праздников, а остальное время он лежит на полке.
Что-то из массового сегмента работает в целом не хуже, теряет в стоимости меньше, а через года два-три его не жалко заменить на более актуальную модель.
💯46❤15🥱6👀5👌1
Я хочу все сделать технически правильно, но мой работодатель препятствует этому
С подобной ситуацией сталкиваются многие коллеги, особенно молодые и искренне недоумевают почему так происходит.
Почему бизнес не хочет делать правильно, а требует костылей, полумер и половинчатых решений. Мол работает и хорошо, а когда перестанет – вот тогда и подумаем.
Обычно в этой ситуации винят руководство, которое представляется жадным и недалеким, плюс ничего не смыслящем в IT-технологиях.
Но на самом деле все обстоит по-другому, просто надо посмотреть на ситуацию с другой стороны. Стороны бизнеса, который оперирует совсем иными понятиями.
Цель любого бизнеса – заработать деньги, а вовсе не сделать все красиво и правильно. Поэтому любой бизнес будет стремиться увеличить прибыль и уменьшить издержки.
IT-отдел – это сугубо расходная статья любого бизнеса, прибыли он не приносит. Поэтому, как и любые другие расходные статьи, он будет финансироваться по принципу оптимального минимума.
Как определяется этот минимум? Далеко не техническими показателями, о них руководство может ничего не знать, да и не обязано. А финансовыми.
Грубо говоря, если проблема решается деньгами, то это не проблема, а расходы. Размер расходов, которые фирма может себе одноразово позволить руководству известен. Как правило он коррелируется с операционной прибылью. Т.е. общей выручкой за вычетом постоянных расходов.
Чем выше этот показатель, тем больше средств фирма может выделить на то, чтобы залить проблему деньгами.
И это вполне нормальная практика. Потому что когда с одной стороны стоят некоторые расходы здесь и сейчас, а с другой возможная проблема где-то там, которая может быть, а может не быть, то включается простой финансовый расчет.
Вот приходит администратор и говорит, что нужно сделать то, то и это. Все это, несомненно правильно и грамотно. Согласно лучшим практикам и рекомендациям.
А руководство его и спрашивает, что будет, если мы это не сделаем?
Админ отвечает, мол то и это, такой-то простой или такая-то потеря данных, ну и прочие негативные факторы.
Следующий вопрос: а какая вероятность этого события. Как часто вообще у нас такое происходило и происходит?
Дальше берется калькулятор и считается количество денег, которые потеряет фирма в результате наступления события, либо какое количество денег понадобится чтобы устранить последствия.
Если эта цифра сравнима с тем, что требуется выделить здесь и сейчас или выше ее, то бизнес деньги выделит. Если же ниже, либо вероятность такого события крайне низка, то в финансировании будет отказано.
Кроме того, есть ряд событий, которые несут угрозу, но вкладывать средства в защиту от них одного только IT не имеет смысла.
Вот приходит админ просить деньги на новые бесперебойники. Сразу вопрос, а зачем?
Ответ, чтобы час тянули, а не 15 минут как сейчас.
Бизнес при этом смотрит шире, и задает встречный вопрос: а зачем нам нужно чтобы сервера работали час, если у нас все рабочие места выключатся через 15 минут?
В результате денег на это, конечно же не дадут. Потому что просто расход в никуда, не несущий для бизнеса практического смысла.
Можно, конечно, нагнать жути и финансирование выбить. Но может так случиться, что указанное событие возьмет и произойдет. И при этом выяснится, что на самом деле все не так уж и страшно, а денег в свое время было выделено неоправданно много.
Возможно, конкретных оргвыводов и не последует, но денег вам больше не дадут или будут делить ваши запросы на некий известный только им коэффициент.
А еще хуже, если средства выделили, событие произошло, но отработать так как было заявлено вы его не смогли. Тут уже точно будут и оргвыводы, и неудобные вопросы по поводу того, на что и как были потрачены деньги.
Поэтому, во многих случаях, лучше не бежать с техническими решениями впереди паровоза, т.е. реальных потребностей бизнеса, а трезво оценивать ситуацию, в том числе и с финансовой стороны, что позволит избежать множества недоразумений и конфликтных ситуаций.
С подобной ситуацией сталкиваются многие коллеги, особенно молодые и искренне недоумевают почему так происходит.
Почему бизнес не хочет делать правильно, а требует костылей, полумер и половинчатых решений. Мол работает и хорошо, а когда перестанет – вот тогда и подумаем.
Обычно в этой ситуации винят руководство, которое представляется жадным и недалеким, плюс ничего не смыслящем в IT-технологиях.
Но на самом деле все обстоит по-другому, просто надо посмотреть на ситуацию с другой стороны. Стороны бизнеса, который оперирует совсем иными понятиями.
Цель любого бизнеса – заработать деньги, а вовсе не сделать все красиво и правильно. Поэтому любой бизнес будет стремиться увеличить прибыль и уменьшить издержки.
IT-отдел – это сугубо расходная статья любого бизнеса, прибыли он не приносит. Поэтому, как и любые другие расходные статьи, он будет финансироваться по принципу оптимального минимума.
Как определяется этот минимум? Далеко не техническими показателями, о них руководство может ничего не знать, да и не обязано. А финансовыми.
Грубо говоря, если проблема решается деньгами, то это не проблема, а расходы. Размер расходов, которые фирма может себе одноразово позволить руководству известен. Как правило он коррелируется с операционной прибылью. Т.е. общей выручкой за вычетом постоянных расходов.
Чем выше этот показатель, тем больше средств фирма может выделить на то, чтобы залить проблему деньгами.
И это вполне нормальная практика. Потому что когда с одной стороны стоят некоторые расходы здесь и сейчас, а с другой возможная проблема где-то там, которая может быть, а может не быть, то включается простой финансовый расчет.
Вот приходит администратор и говорит, что нужно сделать то, то и это. Все это, несомненно правильно и грамотно. Согласно лучшим практикам и рекомендациям.
А руководство его и спрашивает, что будет, если мы это не сделаем?
Админ отвечает, мол то и это, такой-то простой или такая-то потеря данных, ну и прочие негативные факторы.
Следующий вопрос: а какая вероятность этого события. Как часто вообще у нас такое происходило и происходит?
Дальше берется калькулятор и считается количество денег, которые потеряет фирма в результате наступления события, либо какое количество денег понадобится чтобы устранить последствия.
Если эта цифра сравнима с тем, что требуется выделить здесь и сейчас или выше ее, то бизнес деньги выделит. Если же ниже, либо вероятность такого события крайне низка, то в финансировании будет отказано.
Кроме того, есть ряд событий, которые несут угрозу, но вкладывать средства в защиту от них одного только IT не имеет смысла.
Вот приходит админ просить деньги на новые бесперебойники. Сразу вопрос, а зачем?
Ответ, чтобы час тянули, а не 15 минут как сейчас.
Бизнес при этом смотрит шире, и задает встречный вопрос: а зачем нам нужно чтобы сервера работали час, если у нас все рабочие места выключатся через 15 минут?
В результате денег на это, конечно же не дадут. Потому что просто расход в никуда, не несущий для бизнеса практического смысла.
Можно, конечно, нагнать жути и финансирование выбить. Но может так случиться, что указанное событие возьмет и произойдет. И при этом выяснится, что на самом деле все не так уж и страшно, а денег в свое время было выделено неоправданно много.
Возможно, конкретных оргвыводов и не последует, но денег вам больше не дадут или будут делить ваши запросы на некий известный только им коэффициент.
А еще хуже, если средства выделили, событие произошло, но отработать так как было заявлено вы его не смогли. Тут уже точно будут и оргвыводы, и неудобные вопросы по поводу того, на что и как были потрачены деньги.
Поэтому, во многих случаях, лучше не бежать с техническими решениями впереди паровоза, т.е. реальных потребностей бизнеса, а трезво оценивать ситуацию, в том числе и с финансовой стороны, что позволит избежать множества недоразумений и конфликтных ситуаций.
🔥31💯15😁9👍5❤3
Похоже, что WhatsApp - всё. На ПК не работает ни приложение, ни веб-версия.
Долгая загрузка с последующим сообщением, что интернет недоступен.
Мобильное приложение худо-бедно работает. Но сообщения доставляются с большими задержками и очень плохо грузится мультимедиа.
При этом проблемы с WhatsApp начались еще на прошлой неделе, но теперь, похоже, вопрос решили закрыть полностью.
Долгая загрузка с последующим сообщением, что интернет недоступен.
Мобильное приложение худо-бедно работает. Но сообщения доставляются с большими задержками и очень плохо грузится мультимедиа.
При этом проблемы с WhatsApp начались еще на прошлой неделе, но теперь, похоже, вопрос решили закрыть полностью.
👍40🤷♂16😁5⚡4💯4