Сказка о потерянном времени
В очередной раз помогали коллегам заказчика делать инвентаризацию. И в очередной раз нашли много неиспользуемого, включая то, про что давно забыли и были приятно удивлены количеством освободившихся ресурсов.
А пока мы решили составить свой рейтинг ненужности, возможно у вас он будет другой, ждем ваших комментариев.
1️⃣ На первом месте с огромным отрывом стоят локальные базы знаний, чаще всего выполненные на Wiki-движках, но абсолютно необязательно.
Причина проста – такой базой знаний должен кто-то заниматься, причем заниматься постоянно. Если этого нет, то база утрачивает актуальность и ей просто перестают пользоваться, а если перестают пользоваться, то какой смысл ее пополнять.
Сейчас, на просьбы заказчика сделать им такой сервис мы сразу отвечаем, что сделать его – это только 1% от все работы. Остальное – это наполнение и тут им придется уже как-то самим. Обычно, когда дело доходит до конкретной реализации и назначения ответственных энтузиазм как-то сам утихает.
2️⃣ Второе место – это всякие внутренние порталы. В теории это видится некой точкой консолидации, в которой размещают новости, объявления, внутренние документы, инструкции и т.д. и т.п.
Но, на практике, всем этим снова нужно кому-то заниматься. И если нет специально назначенного за этим человека, то такой портал становится нафиг никому не нужным.
Еще меньше он нужен сотрудникам, что надо – доведет руководство. Да и все остальное легче передать через систему совместной работы, тот же Битрикс 24 или аналоги, им хотя бы ежедневно пользуются.
3️⃣ Третье место по ненужности занимает, как это не странно, мониторинг. Но здесь тоже все достаточно прозаично. Ожидания не совпадают с реальностью. Многие представляют мониторинг как красивые графики и диаграммы, которые можно вывести на отдельный монитор и с гордостью показывать начальству.
А по факту получаем кучу метрик, не меньше алертов, которые приходят по делу и без дела и необходимость серьезно вникать и настраивать продукт. После чего тот же условный Zabbix задвигается на самый дальний сервер и благополучно забывается.
4️⃣ Четвертое место, хотя можно и поменять местами с мониторингом, это системы учета заявок и инцидентов, тот же GLPI. Но мы все-таки вынесли его на четвертое, потому что внедряют его уже более-менее осознанно и данные системы менее популярны у начинающих, нежели мониторинги.
Но чтобы у вас работала система учета заявок, у вас уже должна быть работа с заявками или осознанная необходимость и политическая воля в ее создании и внедрении. Потому как инструмент выбирается для решения задачи, а не наоборот.
Вы же не покупаете отбойный молоток просто так и только потом начинаете искать куда бы его применить.
Если нет системы работы с заявками, равно как и самой культуры такой работы, то данный сервис окажется бесполезен и поигравшись месяц другой о нем все забудут.
5️⃣ На следующее место мы бы поставили различные средства наблюдения и управления инфраструктурой, раздел это довольно обширный и отнести к нему можно много чего, скажем тот же IPAM или Ansible.
Пятое место здесь потому, что внедряются такие вещи хотя бы уже с базовым пониманием что и как, но очень часто их внедрение обусловлено не необходимостью, а желанием админа поиграться с новой «крутой» технологией. Но со временем играться надоедает и все это переходит в разряд ненужного.
Еще один вариант, это когда инструменты явно перерастают потребности и квалификацию персонала. Понятно, что это круто, но нафиг никому не нужно. Чаще всего такие проекты тихо саботируются и тут же сворачиваются после ухода инициатора или потери его интереса к проекту.
👆 А по факту все это – потерянное время и ресурсы. И каждый раз, когда возникнет желание внедрить что-нибудь такое следует спросить себя - а оно мне точно нужно? А зачем? А нужно ли оно еще кому-нибудь кроме меня?
И если вы затрудняетесь дать твердые и аргументированные ответы – оно вам не нужно.
В очередной раз помогали коллегам заказчика делать инвентаризацию. И в очередной раз нашли много неиспользуемого, включая то, про что давно забыли и были приятно удивлены количеством освободившихся ресурсов.
А пока мы решили составить свой рейтинг ненужности, возможно у вас он будет другой, ждем ваших комментариев.
1️⃣ На первом месте с огромным отрывом стоят локальные базы знаний, чаще всего выполненные на Wiki-движках, но абсолютно необязательно.
Причина проста – такой базой знаний должен кто-то заниматься, причем заниматься постоянно. Если этого нет, то база утрачивает актуальность и ей просто перестают пользоваться, а если перестают пользоваться, то какой смысл ее пополнять.
Сейчас, на просьбы заказчика сделать им такой сервис мы сразу отвечаем, что сделать его – это только 1% от все работы. Остальное – это наполнение и тут им придется уже как-то самим. Обычно, когда дело доходит до конкретной реализации и назначения ответственных энтузиазм как-то сам утихает.
2️⃣ Второе место – это всякие внутренние порталы. В теории это видится некой точкой консолидации, в которой размещают новости, объявления, внутренние документы, инструкции и т.д. и т.п.
Но, на практике, всем этим снова нужно кому-то заниматься. И если нет специально назначенного за этим человека, то такой портал становится нафиг никому не нужным.
Еще меньше он нужен сотрудникам, что надо – доведет руководство. Да и все остальное легче передать через систему совместной работы, тот же Битрикс 24 или аналоги, им хотя бы ежедневно пользуются.
3️⃣ Третье место по ненужности занимает, как это не странно, мониторинг. Но здесь тоже все достаточно прозаично. Ожидания не совпадают с реальностью. Многие представляют мониторинг как красивые графики и диаграммы, которые можно вывести на отдельный монитор и с гордостью показывать начальству.
А по факту получаем кучу метрик, не меньше алертов, которые приходят по делу и без дела и необходимость серьезно вникать и настраивать продукт. После чего тот же условный Zabbix задвигается на самый дальний сервер и благополучно забывается.
4️⃣ Четвертое место, хотя можно и поменять местами с мониторингом, это системы учета заявок и инцидентов, тот же GLPI. Но мы все-таки вынесли его на четвертое, потому что внедряют его уже более-менее осознанно и данные системы менее популярны у начинающих, нежели мониторинги.
Но чтобы у вас работала система учета заявок, у вас уже должна быть работа с заявками или осознанная необходимость и политическая воля в ее создании и внедрении. Потому как инструмент выбирается для решения задачи, а не наоборот.
Вы же не покупаете отбойный молоток просто так и только потом начинаете искать куда бы его применить.
Если нет системы работы с заявками, равно как и самой культуры такой работы, то данный сервис окажется бесполезен и поигравшись месяц другой о нем все забудут.
5️⃣ На следующее место мы бы поставили различные средства наблюдения и управления инфраструктурой, раздел это довольно обширный и отнести к нему можно много чего, скажем тот же IPAM или Ansible.
Пятое место здесь потому, что внедряются такие вещи хотя бы уже с базовым пониманием что и как, но очень часто их внедрение обусловлено не необходимостью, а желанием админа поиграться с новой «крутой» технологией. Но со временем играться надоедает и все это переходит в разряд ненужного.
Еще один вариант, это когда инструменты явно перерастают потребности и квалификацию персонала. Понятно, что это круто, но нафиг никому не нужно. Чаще всего такие проекты тихо саботируются и тут же сворачиваются после ухода инициатора или потери его интереса к проекту.
👆 А по факту все это – потерянное время и ресурсы. И каждый раз, когда возникнет желание внедрить что-нибудь такое следует спросить себя - а оно мне точно нужно? А зачем? А нужно ли оно еще кому-нибудь кроме меня?
И если вы затрудняетесь дать твердые и аргументированные ответы – оно вам не нужно.
👍61⚡1
Какие сервисы в вашей практике становились самыми ненужными (можно выбрать несколько ответов)
Anonymous Poll
37%
Локальные вики и базы знаний
34%
Локальные порталы
8%
Мониторинг
19%
Системы учета заявок
8%
Системы управления инфраструктурой
5%
Другое (в комментариях)
14%
Ничего не понятно, но очень интересно
22%
Что мне сказали, то я и внедрил. А кому это нужно - не мое дело.
👍8
Каждый месяц мы любим читать и анализировать статистику, как канала, так и сайта. И иногда находим там совершенно изумительные вещи.
Так и в этот раз в списке ссылающихся нашли канал нашего коллеги - сисадмина, но пишет он не о работе, а о жизни, а по работе посылает или к нам, или к Владимиру https://yangx.top/srv_admin (вот так вот, на старости лет стал тем, к кому посылают).
Перешел, почитал канал и меня зацепило. Особенно последний пост про авралы и водку. Было что-то такое, расскажу как-нибудь.
👉 https://yangx.top/winvan_true_original/172
Только вот у него всего 42 подписчика. Может мы хотя бы 420 сделаем? Какой моральный заряд будет автору? Сделаем же?
Данная заметка написана нами в поддержку начинающих авторов, почему это важно – можно прочитать здесь: https://yangx.top/interface31/3702
Так и в этот раз в списке ссылающихся нашли канал нашего коллеги - сисадмина, но пишет он не о работе, а о жизни, а по работе посылает или к нам, или к Владимиру https://yangx.top/srv_admin (вот так вот, на старости лет стал тем, к кому посылают).
Перешел, почитал канал и меня зацепило. Особенно последний пост про авралы и водку. Было что-то такое, расскажу как-нибудь.
👉 https://yangx.top/winvan_true_original/172
Только вот у него всего 42 подписчика. Может мы хотя бы 420 сделаем? Какой моральный заряд будет автору? Сделаем же?
Данная заметка написана нами в поддержку начинающих авторов, почему это важно – можно прочитать здесь: https://yangx.top/interface31/3702
👍25❤1
Как я внедрял систему учета обращений на бумажном носителе
Я уже рассказывал на данном канале истории из далекой молодости, когда я сразу после окончания высшего учебного заведения попал на работу в сельскохозяйственный НИИ на должность инженера.
Первоначально там предполагались задачи администратора, но постепенно на меня скинули все обязанности типового инженера данной конторы вплоть до газовых баллонов, пневматики и всего такого разного.
Сия организация была бюджетной и руководил ей бывший партийный начальник областного уровня, славный в свое время «подвигами», о которых из уст в уста передавались «легенды».
Контингент той конторы был преимущественно предпенсионного возраста, а «молодежь» были те, кому за тридцать. Ну и я со своими 20 с небольшим числился там за «юношу».
Очень скоро я познал… нет, не дзен, а суровую реальность бюджетной конторы – если можно не работать, то работать не нужно, а ответственность всегда можно спихнуть на кого-то другого.
В результате на собраниях по утрам меня часто вызывали на ковер к директору, потому что какой-то отдел чего-то там вовремя не сделал, а причиной назвал неисправность оборудования.
А дальше был примерно следующий диалог:
- Товарищ инженер, ну что это за дела?
- Товарищ директор, первый раз сейчас слышу.
- А мы тебе говорили!!!
- Когда?
- Когда ты баллон менял в понедельник!!!
- Не было такого!
- Было!!!
- Не было!
- Ты гляди, он еще и огрызается! Я тут 100500 лет работаю, а он без году неделя!!!
В результате подобные совещания заканчивались далеко не в мою пользу и получалось что инженер нефига не делает и вообще крайний.
Понятно, что такое положение дел мне не нравилось. Поэтому я взял толстую тетрадку, разлинеил ее и каждое утро, через полчаса после начала рабочего дня начал делать обход.
Я с этой тетрадкой заходил в каждый кабинет и спрашивал – есть ли вопросы по технике или нарекания. Нет? Отмечал в тетрадке: кабинет – прибор – наличие или отсутствие вопросов, дату и время.
Все обращения записывал туда-же. Дату и время обращения, его суть, коротко причину и принятые меры и время завершения. Или объективную невозможность завершить работы, например, нужно купить запасные части.
Со временем одна тетрадка превратилась во две. Одну я назвал «Журнал учета состояния техники», вторую «Журнал учета обращений». С одной делал обход, в другой фиксировал все заявки.
И потом на подобных совещаниях я просто приходил с тетрадками, открывал их и говорил, что обращений не получал, а если получал, то исправил тогда-то и тогда-то, либо не исправил по объективным причинам, так как…
Вся эта система была выстроена мною где-то за полгода, ну да когда получаешь отнюдь не пряники на каждом совещании – думать и шевелиться начнешь.
А потом она прижилась и тихо стала официальной, теперь уже не только я вел эту тетрадку, но и каждый отдел и расписывались в ней обе стороны.
Я проработал в этом НИИ ровно два года, но эта система осталась там надолго и уже лет через 10-15 при общении с бывшими коллегами я узнавал, что система обходов и журналов там до сих про живее всех живых.
Я уже рассказывал на данном канале истории из далекой молодости, когда я сразу после окончания высшего учебного заведения попал на работу в сельскохозяйственный НИИ на должность инженера.
Первоначально там предполагались задачи администратора, но постепенно на меня скинули все обязанности типового инженера данной конторы вплоть до газовых баллонов, пневматики и всего такого разного.
Сия организация была бюджетной и руководил ей бывший партийный начальник областного уровня, славный в свое время «подвигами», о которых из уст в уста передавались «легенды».
Контингент той конторы был преимущественно предпенсионного возраста, а «молодежь» были те, кому за тридцать. Ну и я со своими 20 с небольшим числился там за «юношу».
Очень скоро я познал… нет, не дзен, а суровую реальность бюджетной конторы – если можно не работать, то работать не нужно, а ответственность всегда можно спихнуть на кого-то другого.
В результате на собраниях по утрам меня часто вызывали на ковер к директору, потому что какой-то отдел чего-то там вовремя не сделал, а причиной назвал неисправность оборудования.
А дальше был примерно следующий диалог:
- Товарищ инженер, ну что это за дела?
- Товарищ директор, первый раз сейчас слышу.
- А мы тебе говорили!!!
- Когда?
- Когда ты баллон менял в понедельник!!!
- Не было такого!
- Было!!!
- Не было!
- Ты гляди, он еще и огрызается! Я тут 100500 лет работаю, а он без году неделя!!!
В результате подобные совещания заканчивались далеко не в мою пользу и получалось что инженер нефига не делает и вообще крайний.
Понятно, что такое положение дел мне не нравилось. Поэтому я взял толстую тетрадку, разлинеил ее и каждое утро, через полчаса после начала рабочего дня начал делать обход.
Я с этой тетрадкой заходил в каждый кабинет и спрашивал – есть ли вопросы по технике или нарекания. Нет? Отмечал в тетрадке: кабинет – прибор – наличие или отсутствие вопросов, дату и время.
Все обращения записывал туда-же. Дату и время обращения, его суть, коротко причину и принятые меры и время завершения. Или объективную невозможность завершить работы, например, нужно купить запасные части.
Со временем одна тетрадка превратилась во две. Одну я назвал «Журнал учета состояния техники», вторую «Журнал учета обращений». С одной делал обход, в другой фиксировал все заявки.
И потом на подобных совещаниях я просто приходил с тетрадками, открывал их и говорил, что обращений не получал, а если получал, то исправил тогда-то и тогда-то, либо не исправил по объективным причинам, так как…
Вся эта система была выстроена мною где-то за полгода, ну да когда получаешь отнюдь не пряники на каждом совещании – думать и шевелиться начнешь.
А потом она прижилась и тихо стала официальной, теперь уже не только я вел эту тетрадку, но и каждый отдел и расписывались в ней обе стороны.
Я проработал в этом НИИ ровно два года, но эта система осталась там надолго и уже лет через 10-15 при общении с бывшими коллегами я узнавал, что система обходов и журналов там до сих про живее всех живых.
👍64🔥21😁18❤2
Про нетехнические особенности работы в бюджетной сфере
В обсуждениях вчера снова возник интересный вопрос, который очень характерен для бюджетной сферы и нынешних госов. Но также может касаться и крупного бизнеса, который действует по аналогичной схеме.
А называется это освоением бюджетов. Общий смысл такой, что на год, полгода, квартал или месяц формируются бюджеты и выделяется целевое финансирование. Если ты его запросил – то должен потратить. Иначе ты работаешь неэффективно и в следующий раз тебе столько не дадут.
При этом финансирование целевое и ты не можешь статью на сайт потратить на картриджи, а деньги на картриджи для покупки сгоревшего коммутатора.
В целом такая система достаточно грамотная и позволяет эффективно планировать ресурсы предприятия, когда отделы заранее подают заявки на финансирование, но в бюджетке все, как всегда. А как известно, даже самую здравую идею всегда можно довести до абсурда.
Степень абсурда разнится от конторы к конторе, но общий смысл действующего подхода такой: если вы не освоили бюджет, то больше вам столько денег не дадут. И там хоть трава не расти.
А как планировать? Хорошо если можно расписать помесячно и запросить в какой-то месяц побольше, в какой-то поменьше и перераспределить общий бюджет между статьями. А когда нет?
Ну и случиться на протяжении бюджетного периода может всякое, на это тоже надо заложиться. В общем принцип там следующий – проси больше, получишь сколько надо.
А потом получается, что деньги к концу бюджетного периода остались и их срочно надо куда-то потратить. А куда? Ну давайте купим что-нибудь нужное, или не совсем нужное, или совсем ненужное.
Хорошо если это железо, можно закупиться впрок и даже можно у поставщика его забрать только через полгода, после неоднократных напоминаний.
Это приводит к тому, что в отдельных конторах могут накапливаться штабеля нового железа, в заводской упаковке, которое никому не нужно. Почему не нужно? Да потому что под новые проекты берутся новые железки, потому что там тоже бюджет и его тоже надо осваивать.
При этом подобные вещи могут самым чудесным образом сосуществовать с полными дровами у пользователей, которые продолжают работать на древних тормозных ПК, просто потому что на его обновление не выделен бюджет. А зачем, работает ведь.
Но… Но там совсем другое дело, там же цифровизация, импортозамещение и всякие разные программы, начиная от федеральных и за них надо отчитывается, поэтому туда бюджеты находятся.
А если ты скажешь, что есть у нас на складе и сервера и все и остальное, давайте на эти деньги обновим ПК сотрудникам, то тебе быстро и доходчиво объяснят – что это нецелевое расходование бюджетных средств и за это может даже быть «садись кибитка – тюрьма поехали».
Но это еще половина беды, практически везде к этой крайне неэффективной практике добавляется личный фактор, который сводится к такому широко известному в узких кругах слову как откат.
Случайных людей в поставщиках или подрядчиках у бюджетки нет, там все свои. То, что можно протащить без торгов – протаскивается так. Что нельзя – конкурсное задание составляется так, чтобы выиграть его гарантированно мог только один, свой, поставщик.
А дальше представители поставщика и заказчика садятся вместе в тихом укромном месте и решают, как и на что они будут пилить бюджет и сколько из бюджетных денег… ну в общем вы поняли. Зарплаты в бюджетке невысокие, а жене надо новую шубу, себе новый авто, летом на юга и т.д. и т.п.
А дальше все зависит от наглости и ловкости, причем эта схема в бюджете поголовно. Да, кого-то ловят и иногда сажают, но в большинстве товарищи годами сидят на теплых местах и осваивают бюджеты.
Отсюда и возникают такие задачи: а давайте… давайте… давайте… внедрим что-нибудь такое, где и железа купить можно и услуг написать побольше…
Внедрили, освоили, разделили. А что нам теперь с этим делать? Да ничего, задвиньте на дальнюю стойку, пусть стоит, небо коптит. Деньги освоили, наверх красиво отчитались. Надо думать как дальше бюджет осваивать, а не эти ваши Заббиксы и Вики.
В обсуждениях вчера снова возник интересный вопрос, который очень характерен для бюджетной сферы и нынешних госов. Но также может касаться и крупного бизнеса, который действует по аналогичной схеме.
А называется это освоением бюджетов. Общий смысл такой, что на год, полгода, квартал или месяц формируются бюджеты и выделяется целевое финансирование. Если ты его запросил – то должен потратить. Иначе ты работаешь неэффективно и в следующий раз тебе столько не дадут.
При этом финансирование целевое и ты не можешь статью на сайт потратить на картриджи, а деньги на картриджи для покупки сгоревшего коммутатора.
В целом такая система достаточно грамотная и позволяет эффективно планировать ресурсы предприятия, когда отделы заранее подают заявки на финансирование, но в бюджетке все, как всегда. А как известно, даже самую здравую идею всегда можно довести до абсурда.
Степень абсурда разнится от конторы к конторе, но общий смысл действующего подхода такой: если вы не освоили бюджет, то больше вам столько денег не дадут. И там хоть трава не расти.
А как планировать? Хорошо если можно расписать помесячно и запросить в какой-то месяц побольше, в какой-то поменьше и перераспределить общий бюджет между статьями. А когда нет?
Ну и случиться на протяжении бюджетного периода может всякое, на это тоже надо заложиться. В общем принцип там следующий – проси больше, получишь сколько надо.
А потом получается, что деньги к концу бюджетного периода остались и их срочно надо куда-то потратить. А куда? Ну давайте купим что-нибудь нужное, или не совсем нужное, или совсем ненужное.
Хорошо если это железо, можно закупиться впрок и даже можно у поставщика его забрать только через полгода, после неоднократных напоминаний.
Это приводит к тому, что в отдельных конторах могут накапливаться штабеля нового железа, в заводской упаковке, которое никому не нужно. Почему не нужно? Да потому что под новые проекты берутся новые железки, потому что там тоже бюджет и его тоже надо осваивать.
При этом подобные вещи могут самым чудесным образом сосуществовать с полными дровами у пользователей, которые продолжают работать на древних тормозных ПК, просто потому что на его обновление не выделен бюджет. А зачем, работает ведь.
Но… Но там совсем другое дело, там же цифровизация, импортозамещение и всякие разные программы, начиная от федеральных и за них надо отчитывается, поэтому туда бюджеты находятся.
А если ты скажешь, что есть у нас на складе и сервера и все и остальное, давайте на эти деньги обновим ПК сотрудникам, то тебе быстро и доходчиво объяснят – что это нецелевое расходование бюджетных средств и за это может даже быть «садись кибитка – тюрьма поехали».
Но это еще половина беды, практически везде к этой крайне неэффективной практике добавляется личный фактор, который сводится к такому широко известному в узких кругах слову как откат.
Случайных людей в поставщиках или подрядчиках у бюджетки нет, там все свои. То, что можно протащить без торгов – протаскивается так. Что нельзя – конкурсное задание составляется так, чтобы выиграть его гарантированно мог только один, свой, поставщик.
А дальше представители поставщика и заказчика садятся вместе в тихом укромном месте и решают, как и на что они будут пилить бюджет и сколько из бюджетных денег… ну в общем вы поняли. Зарплаты в бюджетке невысокие, а жене надо новую шубу, себе новый авто, летом на юга и т.д. и т.п.
А дальше все зависит от наглости и ловкости, причем эта схема в бюджете поголовно. Да, кого-то ловят и иногда сажают, но в большинстве товарищи годами сидят на теплых местах и осваивают бюджеты.
Отсюда и возникают такие задачи: а давайте… давайте… давайте… внедрим что-нибудь такое, где и железа купить можно и услуг написать побольше…
Внедрили, освоили, разделили. А что нам теперь с этим делать? Да ничего, задвиньте на дальнюю стойку, пусть стоит, небо коптит. Деньги освоили, наверх красиво отчитались. Надо думать как дальше бюджет осваивать, а не эти ваши Заббиксы и Вики.
👍55🔥12🥱6💯4
Универсальные инструменты 1С для управляемых форм
Несколько дней назад обнаружили интересный и полезный проект для всех, кто связан с 1С. Данный инструмент содержит самые необходимые обработки для разработчика, администратора или опытного пользователя 1С. Причем большинство обработок в наборе предназначены именно последним.
Инструменты распространяются в виде файла конфигурации, расширения или в портативном варианте в виде внешней обработки.
В целом ничего сверхъестественного там нет, многие из включенных в комплект обработок можно найти на Инфостарте, но здесь все это собрано в одном месте, проверено и доработано.
Что важно, все инструменты работают как под Windows, так и под Linux, а это важно, например, популярная стандартная обработка Выгрузка загрука XML без доработки с Linux серверами не работает. И таких моментов много. А так как основной парк серверов 1С у нас на Linux, то мы по достоинству оценили этот момент.
✅ https://github.com/cpr1c/tools_ui_1c
Несколько дней назад обнаружили интересный и полезный проект для всех, кто связан с 1С. Данный инструмент содержит самые необходимые обработки для разработчика, администратора или опытного пользователя 1С. Причем большинство обработок в наборе предназначены именно последним.
Инструменты распространяются в виде файла конфигурации, расширения или в портативном варианте в виде внешней обработки.
В целом ничего сверхъестественного там нет, многие из включенных в комплект обработок можно найти на Инфостарте, но здесь все это собрано в одном месте, проверено и доработано.
Что важно, все инструменты работают как под Windows, так и под Linux, а это важно, например, популярная стандартная обработка Выгрузка загрука XML без доработки с Linux серверами не работает. И таких моментов много. А так как основной парк серверов 1С у нас на Linux, то мы по достоинству оценили этот момент.
✅ https://github.com/cpr1c/tools_ui_1c
👍48
Как поставить в отраслевую конфигурацию 1С:Предприятие патчи от родительской конфигурации.
Отраслевые конфигурации 1С рассказ отдельный и бесконечно грустный. Многие из тех, кто столкнулись с этим разделом «творчества» предпочтут во множестве ситуаций дорабатывать и сопровождать типовые самостоятельно, нежели еще раз связываться с отраслевыми.
При том что отраслевые сильно дороже, как по стоимости прикладного решения, так и по сопровождению, где-то так раза в два. Казалось бы, вместе с готовыми доработками для отрасли логично получать и своевременную поддержку, хотя бы в виде своевременного исправления ошибок и выпуска исправлений.
На деле же пользователь отраслевой часто получает кучу проблем на ровном месте и полное безразличие со стороны вендора, включая никакую поддержку. Да и сам состав решений очень часто вызывает недоумение, создавая впечатление что разработчики знакомились с отраслью по книжкам для профориентации младших начальных классов.
Чтобы не быть голословными перейдем к 1С:Розница 8. Салон оптики. Это конфигурация на базе типовой 1С:Розница 8 от компании Рарус, у нее там целая линейка подобного творчества на все случаи жизни.
А теперь сравним:
🔹 1С:Розница 8 ПРОФ. Электронная поставка – 17 600 руб.
🔹1С:Розница 8. Салон оптики. Электронная поставка – 31 100 руб.
Для поддержки вам потребуется не только ИТС, но еще и КП отраслевой 2 категории (тарифы на 12 месяцев):
🔹 1С:ИТС Техно – 21 204 руб.
🔹 1С:КП Отраслевой Базовый 2-я Категория – 27 800 руб.
Логично предположить, что за эти деньги покупатель должен получить некоторую дополнительную ценность. Но увы. Мы не будем разбирать состав конкретных отраслевых, а сосредоточимся на поддержке, которая идет отдельной строкой и стоит дороже подписки ИТС.
Итак, на руках у нас имеется обновление 1С:Розница 8. Салон оптики 2.3.21.29 от 25.12.24 (типовая с таким же номером выпущена 12.12.24), т.е. временной лаг между ними где-то две недели.
Данный релиз еще на уровне типовой имеет ряд ошибок, некоторые из них достаточно критичные, например, EF_00_00691163 (патч выпущен 25.12.2024):
▫️ В организации с применением УНС 5%(7%) товары с установленной ставкой: без НДС и НДС0% пробиваются в чек со ставкой 5%(7%).
Ошибка для большинства клиник критичная, так как медицинские услуги оказываемые в рамках медицинской лицензии НДС не облагаются, даже если компания применяет ставки 5/7 % НДС.
И что вы думаете в отраслевой? За которую заказчик отдельно платит вдвое более дорогую поддержку?
А ничего 🍌🍌🍌, фирма Рарус считает, что исправления ошибок для релиза 2.3.21.29 не требуются, в то время как фирма 1С выпустила для типовой 1С:Розница указанного релиза 51 патч.
Можно, конечно, подождать следующего релиза, в котором эти ошибки (возможно) исправят, а новых, неизбежно добавят. Но это не дело, по факту мы получаем сырой и недоработанный продукт и находимся в заведомо более худшей ситуации, чем пользователи типовой.
Как быть? Известно, что спасение утопающих – дело рук самих утопающих, поэтому было принято решение попробовать использовать официальные патчи от типовой конфигурации.
Но если попробовать их загрузить в лоб, в виде архива, то программа откажется их принимать, потому что патчи «не той системы». Поэтому распакуем архив, в котором будет файл расширения и манифест.
Манифест выбрасываем, а расширение устанавливаем стандартным способом через форму работы с расширениями, при этом конфигурация распознает в расширении патч и устанавливает его именно как патч. И в последствии вы будете видеть его в списке исправлений, а не расширений.
Насколько это легально? Скажем честно – не особо, если вы не имеете правомерного доступа к типовой Рознице (т.е. нет купленной конфигурации). Но, с другой стороны, вы платите за поддержку и поддержки не получаете. Поэтому определенное моральное право так поступать имеете. А дальше каждый решает сам.
Если доступ к патчам является критичным, то приобрести лицензию на 1С:Розница 8 ПРОФ будет меньшим из зол, все остальные нужные подписки у вас уже есть.
Отраслевые конфигурации 1С рассказ отдельный и бесконечно грустный. Многие из тех, кто столкнулись с этим разделом «творчества» предпочтут во множестве ситуаций дорабатывать и сопровождать типовые самостоятельно, нежели еще раз связываться с отраслевыми.
При том что отраслевые сильно дороже, как по стоимости прикладного решения, так и по сопровождению, где-то так раза в два. Казалось бы, вместе с готовыми доработками для отрасли логично получать и своевременную поддержку, хотя бы в виде своевременного исправления ошибок и выпуска исправлений.
На деле же пользователь отраслевой часто получает кучу проблем на ровном месте и полное безразличие со стороны вендора, включая никакую поддержку. Да и сам состав решений очень часто вызывает недоумение, создавая впечатление что разработчики знакомились с отраслью по книжкам для профориентации младших начальных классов.
Чтобы не быть голословными перейдем к 1С:Розница 8. Салон оптики. Это конфигурация на базе типовой 1С:Розница 8 от компании Рарус, у нее там целая линейка подобного творчества на все случаи жизни.
А теперь сравним:
🔹 1С:Розница 8 ПРОФ. Электронная поставка – 17 600 руб.
🔹1С:Розница 8. Салон оптики. Электронная поставка – 31 100 руб.
Для поддержки вам потребуется не только ИТС, но еще и КП отраслевой 2 категории (тарифы на 12 месяцев):
🔹 1С:ИТС Техно – 21 204 руб.
🔹 1С:КП Отраслевой Базовый 2-я Категория – 27 800 руб.
Логично предположить, что за эти деньги покупатель должен получить некоторую дополнительную ценность. Но увы. Мы не будем разбирать состав конкретных отраслевых, а сосредоточимся на поддержке, которая идет отдельной строкой и стоит дороже подписки ИТС.
Итак, на руках у нас имеется обновление 1С:Розница 8. Салон оптики 2.3.21.29 от 25.12.24 (типовая с таким же номером выпущена 12.12.24), т.е. временной лаг между ними где-то две недели.
Данный релиз еще на уровне типовой имеет ряд ошибок, некоторые из них достаточно критичные, например, EF_00_00691163 (патч выпущен 25.12.2024):
▫️ В организации с применением УНС 5%(7%) товары с установленной ставкой: без НДС и НДС0% пробиваются в чек со ставкой 5%(7%).
Ошибка для большинства клиник критичная, так как медицинские услуги оказываемые в рамках медицинской лицензии НДС не облагаются, даже если компания применяет ставки 5/7 % НДС.
И что вы думаете в отраслевой? За которую заказчик отдельно платит вдвое более дорогую поддержку?
А ничего 🍌🍌🍌, фирма Рарус считает, что исправления ошибок для релиза 2.3.21.29 не требуются, в то время как фирма 1С выпустила для типовой 1С:Розница указанного релиза 51 патч.
Можно, конечно, подождать следующего релиза, в котором эти ошибки (возможно) исправят, а новых, неизбежно добавят. Но это не дело, по факту мы получаем сырой и недоработанный продукт и находимся в заведомо более худшей ситуации, чем пользователи типовой.
Как быть? Известно, что спасение утопающих – дело рук самих утопающих, поэтому было принято решение попробовать использовать официальные патчи от типовой конфигурации.
Но если попробовать их загрузить в лоб, в виде архива, то программа откажется их принимать, потому что патчи «не той системы». Поэтому распакуем архив, в котором будет файл расширения и манифест.
Манифест выбрасываем, а расширение устанавливаем стандартным способом через форму работы с расширениями, при этом конфигурация распознает в расширении патч и устанавливает его именно как патч. И в последствии вы будете видеть его в списке исправлений, а не расширений.
Насколько это легально? Скажем честно – не особо, если вы не имеете правомерного доступа к типовой Рознице (т.е. нет купленной конфигурации). Но, с другой стороны, вы платите за поддержку и поддержки не получаете. Поэтому определенное моральное право так поступать имеете. А дальше каждый решает сам.
Если доступ к патчам является критичным, то приобрести лицензию на 1С:Розница 8 ПРОФ будет меньшим из зол, все остальные нужные подписки у вас уже есть.
👍30😢4❤2
Подписывание SMB-пакетов в Samba
В нашей предыдущей заметке мы говорили о подписывании SMB пакетов в Windows.
SMB Signing это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью. Это позволяет предотвратить реализацию SMB атак типа MitM и NTLM relay.
Начиная с Windows 11 24H2 клиент будет требовать обязательного подписывания пакетов, в дальнейшем эту политику обещают распространить на все поддерживаемые ОС.
В Linux также не трудно настроить подписывание пакетов, для этого в секции
Для сервера это
▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено
По умолчанию применяется значение disabled.
Для клиента используется опция
▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено
Значение по умолчанию: auto.
В современных условиях оптимальными настройками будет изменение режима сервера также на auto:
Это позволит работать с современными клиентами, не снижая уровня защиты, но при этом сохраняя совместимость с клиентами не поддерживающими подписывание.
В этом плане Samba позволяет более гибко управлять настройками чем SMB в Windows, там сторона может либо требовать подписывание для всех, либо нет, режим согласования отсутствует.
В нашей предыдущей заметке мы говорили о подписывании SMB пакетов в Windows.
SMB Signing это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью. Это позволяет предотвратить реализацию SMB атак типа MitM и NTLM relay.
Начиная с Windows 11 24H2 клиент будет требовать обязательного подписывания пакетов, в дальнейшем эту политику обещают распространить на все поддерживаемые ОС.
В Linux также не трудно настроить подписывание пакетов, для этого в секции
[global] файла smb.conf потребуется указать две опции.Для сервера это
server signing, которая может принимать следующие значения:▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено
По умолчанию применяется значение disabled.
Для клиента используется опция
client signing с доступными значениями:▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено
Значение по умолчанию: auto.
В современных условиях оптимальными настройками будет изменение режима сервера также на auto:
[global]
server signing = auto
Это позволит работать с современными клиентами, не снижая уровня защиты, но при этом сохраняя совместимость с клиентами не поддерживающими подписывание.
В этом плане Samba позволяет более гибко управлять настройками чем SMB в Windows, там сторона может либо требовать подписывание для всех, либо нет, режим согласования отсутствует.
👍32
Подборка актуальных материалов по Samba
▫️ Настройка файлового сервера Samba на платформе Debian / Ubuntu
▫️ Настраиваем антивирусную защиту в реальном времени на основе ClamAV On Access Scanning
▫️ Исправляем ошибку подключения Windows к общим ресурсам на сервере Samba Linux
▫️ Включаем отображение Samba-сервера в сетевом окружении Windows
▫️ Настройка файлового сервера ksmbd на платформе Debian / Ubuntu
▫️ Монтирование файловых систем при помощи systemd
▫️ Настройка файлового сервера Samba на платформе Debian / Ubuntu
▫️ Настраиваем антивирусную защиту в реальном времени на основе ClamAV On Access Scanning
▫️ Исправляем ошибку подключения Windows к общим ресурсам на сервере Samba Linux
▫️ Включаем отображение Samba-сервера в сетевом окружении Windows
▫️ Настройка файлового сервера ksmbd на платформе Debian / Ubuntu
▫️ Монтирование файловых систем при помощи systemd
👍41❤2
Самый лёгкий способ попасть в Kubernetes
«Лаборатория Числитель» представила «Штурвал CE» — полнофункциональную community-версию платформы для управления кластерами K8s.
«Штурвал» уже стоит во многих крупных компаниях, а теперь его может поставить каждый.
Лицензионный ключ для установки community-версии придет после заполнения формы на сайте.
А вот тут чат с разрабами, вопросы можно туда.
«Лаборатория Числитель» представила «Штурвал CE» — полнофункциональную community-версию платформы для управления кластерами K8s.
«Штурвал» уже стоит во многих крупных компаниях, а теперь его может поставить каждый.
Лицензионный ключ для установки community-версии придет после заполнения формы на сайте.
А вот тут чат с разрабами, вопросы можно туда.
👍3🔥3❤1
В очередной рассылке Let’s Encrypt уведомила о грядущем прекращении рассылки с напоминанием об окончании срока действия сертификата:
В этом же письме они рекомендовали к использованию сторонний сервис для мониторинга сертификатов: https://redsift.com/pulse-platform/certificates-lite
Сервис достаточно функциональный и позволяет в бесплатной версии наблюдать до 250 сертификатов, что более чем достаточно как для личных, так и для корпоративных нужд.
Но есть ложка дегтя – на территории РФ сервис недоступен, через туннель все работает, проблем с добавлением доменов в зоне RU нет, равно как и получение уведомлений на отечественные почтовые службы.
Кому лень регистрироваться – можно войти через Google или Microsoft.
Мы сообщаем вам, что намерены прекратить рассылку электронных писем с уведомлениями об истечении срока действия. Вы можете узнать больше в этом сообщении в блоге. В ближайшие месяцы вы снова получите это электронное письмо с напоминанием.
В этом же письме они рекомендовали к использованию сторонний сервис для мониторинга сертификатов: https://redsift.com/pulse-platform/certificates-lite
Сервис достаточно функциональный и позволяет в бесплатной версии наблюдать до 250 сертификатов, что более чем достаточно как для личных, так и для корпоративных нужд.
Но есть ложка дегтя – на территории РФ сервис недоступен, через туннель все работает, проблем с добавлением доменов в зоне RU нет, равно как и получение уведомлений на отечественные почтовые службы.
Кому лень регистрироваться – можно войти через Google или Microsoft.
👍22🔥4🤔3👌2
По мотивам реальных событий.
▫️ Вася решил мониторить температуру произвольных устройств.
▫️ Вася решил использовать для этого sensors
▫️ Вася добавил в конфигурацию агента Zabbix примерно следующие строки:
👉 Некоторое время все было хорошо, потом метрики стали показывать погоду на Марсе.
❓Что не так сделал Вася?
▫️ Вася решил мониторить температуру произвольных устройств.
▫️ Вася решил использовать для этого sensors
▫️ Вася добавил в конфигурацию агента Zabbix примерно следующие строки:
UserParameter=lm.nvme0Temperature,sensors | tail -n 3 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'
UserParameter=lm.nvme1Temperature,sensors | tail -n 8 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'👉 Некоторое время все было хорошо, потом метрики стали показывать погоду на Марсе.
❓Что не так сделал Вася?
👍5
В чем был не прав Вася?
Итак, давайте разберем творчество нашего Васи и поймем в чем он был не прав. Для этого сначала нам нужно понять, что делает его заклинание.
▫️ Начало понятно, он вызывает команду sensors и потом колдует над ее выводом, передавая его по конвейеру.
▫️ Обработка начинается с команды tail, которая берет указанное количество строк от конца вывода. В нашем случае это три или восемь.
▫️ Этот результат передаем команде head, которая берет оттуда первую переданную строку. Таким образом у нас остается только третья или восьмая строка от конца.
▫️ Затем это все передается команде awk, где и происходит основная магия.
🔹
🔹
🔹
👆 В целом – магия грамотная и особых вопросов к ней нет. Но! Ошибочен сам принцип парсинга вывода команды sensors. Дело в том, что он зависит от количества сенсоров и выводимой ими информации.
Вам достаточно поменять что угодно в аппаратной конфигурации, чтобы изменить набор сенсоров и порядок, и количество строк сразу же поплывут. И на месте третьей и восьмой строки может оказаться все что угодно.
Поэтому не следует парсить любой вывод или файл опираясь только лишь на номера строк, это абсолютно ненадежно.
Как быть? Используйте grep. Находим вывод именно нашего сенсора и начинаем плясать он его имени. Допустим у нас есть:
Нас интересует третья строка, в которое находится искомая температура, поэтому пишем:
Которая выведет нам строку с вхождением и еще две после. Затем откусим нижнюю строку через tail:
И уже все это скормим awk, вычисление средней можно убрать, так как значение у нас одно:
Теперь у нас при любых изменениях количества и порядка строк будет выводиться правильная информация. Либо перестанет выводиться вообще, если такой сенсор пропадет. Но погоды на Марсе уже не будет.
Итак, давайте разберем творчество нашего Васи и поймем в чем он был не прав. Для этого сначала нам нужно понять, что делает его заклинание.
▫️ Начало понятно, он вызывает команду sensors и потом колдует над ее выводом, передавая его по конвейеру.
▫️ Обработка начинается с команды tail, которая берет указанное количество строк от конца вывода. В нашем случае это три или восемь.
▫️ Этот результат передаем команде head, которая берет оттуда первую переданную строку. Таким образом у нас остается только третья или восьмая строка от конца.
▫️ Затем это все передается команде awk, где и происходит основная магия.
🔹
-F'[:+°]' – делим строку по указанным разделителям, искомое нами значение является третьим полем, так как располагается между плюсом и градусом.🔹
{avg+=$3} – суммируем третье поле от всех строк в файле, эта конструкция перекочевала сюда из вышестоящей директивы для процессора, где в выводе не было общей температуры, но была температура по ядрам. В итоге мы отбирали количество строк по числу ядер и выводили среднюю.🔹
END{print avg/NR} – выводит среднее значение разделенное на количество строк в стандартны поток ввода-вывода.👆 В целом – магия грамотная и особых вопросов к ней нет. Но! Ошибочен сам принцип парсинга вывода команды sensors. Дело в том, что он зависит от количества сенсоров и выводимой ими информации.
Вам достаточно поменять что угодно в аппаратной конфигурации, чтобы изменить набор сенсоров и порядок, и количество строк сразу же поплывут. И на месте третьей и восьмой строки может оказаться все что угодно.
Поэтому не следует парсить любой вывод или файл опираясь только лишь на номера строк, это абсолютно ненадежно.
Как быть? Используйте grep. Находим вывод именно нашего сенсора и начинаем плясать он его имени. Допустим у нас есть:
nvme-pci-0100
Adapter: PCI adapter
Composite: +37.9°C (low = -0.1°C, high = +114.8°C)
(crit = +119.8°C)
Нас интересует третья строка, в которое находится искомая температура, поэтому пишем:
sensors | grep nvme-pci-0100 -A 2
Которая выведет нам строку с вхождением и еще две после. Затем откусим нижнюю строку через tail:
sensors | grep nvme-pci-0100 -A 2 | tail -n 1
И уже все это скормим awk, вычисление средней можно убрать, так как значение у нас одно:
sensors | grep nvme-pci-0100 -A 2 | tail -n1 | awk -F'[:+°]' '{print $3}'Теперь у нас при любых изменениях количества и порядка строк будет выводиться правильная информация. Либо перестанет выводиться вообще, если такой сенсор пропадет. Но погоды на Марсе уже не будет.
👍52😁4
Уже видели новость? Слёрм запускает серию вебинаров с экспертами из бигтеха про вакансии в DevOps.
Они хотят максимально честно показать вакансии и компании, чтобы сократить дистанцию между работодателями и соискателями:
🔴 Что реально важно конкретным лидам, когда они набирают команду?
🔴 Готовы ли компании снизить требования к позиции, чтобы ускорить поиск?
🔴 Если бы каждый пункт в вакансии стоил +20к к офферу, какие бы остались?
📆 Первая встреча: 13 февраля в 19:00
Ведущий: Вячеслав Федосеев, TeamLead DevOps в «Честном знаке», автор канала «DevOps Bootcamp с Федосеевым»
Приглашённый гость: Владимир Федорков, основатель fournines.ru
Далее встречи — два раза в неделю по понедельникам и средам. В феврале ждем в гости эйчаров и лидов из VK Cloud, Kaspersky, Инфосистемы Джет.
Расписание, подробности и ссылки на встречи — в боте 📌
#реклама
О рекламодателе
erid: 2W5zFHUFkK2
Они хотят максимально честно показать вакансии и компании, чтобы сократить дистанцию между работодателями и соискателями:
🔴 Что реально важно конкретным лидам, когда они набирают команду?
🔴 Готовы ли компании снизить требования к позиции, чтобы ускорить поиск?
🔴 Если бы каждый пункт в вакансии стоил +20к к офферу, какие бы остались?
📆 Первая встреча: 13 февраля в 19:00
Ведущий: Вячеслав Федосеев, TeamLead DevOps в «Честном знаке», автор канала «DevOps Bootcamp с Федосеевым»
Приглашённый гость: Владимир Федорков, основатель fournines.ru
Далее встречи — два раза в неделю по понедельникам и средам. В феврале ждем в гости эйчаров и лидов из VK Cloud, Kaspersky, Инфосистемы Джет.
Расписание, подробности и ссылки на встречи — в боте 📌
#реклама
О рекламодателе
erid: 2W5zFHUFkK2
👎1
Вроде это знают все, как оказалось - не все.
Linux - начинающим. Потоки, перенаправление потоков, конвейер
После того, как вы освоили базовые принципы работы с Linux, позволяющие более-менее уверенно чувствовать себя в среде этой операционной системы, следует начать углублять свои знания, переходя к более глубоким и фундаментальным принципам, на которых основаны многие приемы работы в ОС.
Одним из важнейших является понятие потоков, которые позволяют передавать данные от одной программы к другой, а также конвейера, позволяющего выстраивать целые цепочки из программ, каждая из которых будет работать с результатом действий предыдущей.
Все это очень широко используется и понимание того, как это работает важно для любого Linux-администратора.
https://interface31.ru/tech_it/2021/10/linux---nachinayushhim-chast-7-potoki-perenapravlenie-potokov-konveyer.html
Linux - начинающим. Потоки, перенаправление потоков, конвейер
После того, как вы освоили базовые принципы работы с Linux, позволяющие более-менее уверенно чувствовать себя в среде этой операционной системы, следует начать углублять свои знания, переходя к более глубоким и фундаментальным принципам, на которых основаны многие приемы работы в ОС.
Одним из важнейших является понятие потоков, которые позволяют передавать данные от одной программы к другой, а также конвейера, позволяющего выстраивать целые цепочки из программ, каждая из которых будет работать с результатом действий предыдущей.
Все это очень широко используется и понимание того, как это работает важно для любого Linux-администратора.
https://interface31.ru/tech_it/2021/10/linux---nachinayushhim-chast-7-potoki-perenapravlenie-potokov-konveyer.html
👍35
Чтоб ты жил в эпоху перемен
Данную фразу приписывают древним китайцам, хотя другие источники говорят о гораздо более позднем ее возникновении, но определенный смысл в ней все равно есть.
Изменения – это не хорошо и не плохо, это неотъемлемая часть нашей жизни и профессиональной деятельности, но плохо, когда изменений слишком много и все они происходят примерно в одно и тоже время.
Применять изменения в IT – это целая наука и каждый хоть раз на этом обжигался. Поэтому сегодня давайте еще раз вернемся к этому вопросу и попробуем выделить базовые основы этого процесса.
Самая большая ошибка – это выполнить все изменения разом, потому что после этого, если что-то пойдет не так, будет совершенно непонятно, что именно стало причиной такого поведения и за что браться в первую очередь. Получится такой пожар во время наводнения.
Поэтому вносить изменения надо постепенно, даже если они «срочные». Сядьте и распишите все что вам требуется изменить. Обычно это изменения нескольких видов:
Обновить существующее ПО/оборудование
Добавить новое ПО/оборудование
Изменить текущие настройки/включить новые
Выписываем это все в отдельный список. После чего выявляем зависимости изменений друг от друга. Скажем, изменить или включить настройки можно только после обновления ПО. Поэтому строим любым удобным образом схему зависимостей одних изменений от других.
Мы, например, предпочитаем использовать для этого интеллект-карты, где можно легко разбить задачу на этапы и указать зависимости, пример такой карты в скриншоте под данной заметкой.
После чего мы будем понимать какие этапы внесения изменений можно выполнить независимо, а какие зависят от других или требуют целого ряда выполненных условий.
Начинаем с тех изменений, которые можно выполнять независимо и начинаем их вносит по следующему плану: внесли – протестировали – вывялили и устранили проблемы – завершили.
После чего, но не ранее, можно переходить к следующему изменению. Это позволит решать проблемы по мере их поступления, а не все разом. При этом вы всегда будете понимать, с каким именно изменением связана проблема.
Говоря о проблемах следует понимать, что не все из них являются техническими, многие окажутся организационными или просто создадут для конечных пользователей ранее неизвестную им ситуацию, которую они определят как проблему и будут обращаться по этому поводу в поддержку.
В связи с этим важно обеспечить соответствующую работу с пользователями, чтобы своевременно сообщить им обо всех изменениях и новых алгоритмах работы, иначе даже выполнив все технически безупречно вы рискуете провалить внедрение в глазах руководства, потому что вовремя не научили пользователей и не подготовили к новым условиям работы.
После того, как вы последовательно выполнили все изменения текущего уровня переходите к следующим. При этом учитывайте зависимости и всегда оставляйте время на тестирование и выявление ошибок.
Такой подход, даже при достаточно сложных изменениях позволяет сохранить контроль и выполнять поиск возникших проблем точечно, понимая с чем примерно они связаны. Потому что вчера у вас все работало, сегодня вы изменили это и это и получили проблему. Куда смотреть более-менее понятно.
В противном случае вы можете уподобиться герою известного анекдота, который ищет часы не там, где потерял, а там, где светлее.
Даже если проблема комплексная и появляется на пересечении нескольких изменений, то тоже будет примерно понятно это комбо, так как вы всегда будете видеть, какой из добавленных или измененных компонентов привел к проблеме и сможете провести причинно-следственные связи, хотя бы примерно определив предполагаемого виновника.
Ну и не забывайте на каждом этапе документировать все вносимые изменения и полученные при этом результаты, это поможет как вам, так и при возможном обращении в поддержку.
Кстати не стесняйтесь обращаться туда, а откуда еще разработчики должны узнать что в их продукте проблема?
Данную фразу приписывают древним китайцам, хотя другие источники говорят о гораздо более позднем ее возникновении, но определенный смысл в ней все равно есть.
Изменения – это не хорошо и не плохо, это неотъемлемая часть нашей жизни и профессиональной деятельности, но плохо, когда изменений слишком много и все они происходят примерно в одно и тоже время.
Применять изменения в IT – это целая наука и каждый хоть раз на этом обжигался. Поэтому сегодня давайте еще раз вернемся к этому вопросу и попробуем выделить базовые основы этого процесса.
Самая большая ошибка – это выполнить все изменения разом, потому что после этого, если что-то пойдет не так, будет совершенно непонятно, что именно стало причиной такого поведения и за что браться в первую очередь. Получится такой пожар во время наводнения.
Поэтому вносить изменения надо постепенно, даже если они «срочные». Сядьте и распишите все что вам требуется изменить. Обычно это изменения нескольких видов:
Обновить существующее ПО/оборудование
Добавить новое ПО/оборудование
Изменить текущие настройки/включить новые
Выписываем это все в отдельный список. После чего выявляем зависимости изменений друг от друга. Скажем, изменить или включить настройки можно только после обновления ПО. Поэтому строим любым удобным образом схему зависимостей одних изменений от других.
Мы, например, предпочитаем использовать для этого интеллект-карты, где можно легко разбить задачу на этапы и указать зависимости, пример такой карты в скриншоте под данной заметкой.
После чего мы будем понимать какие этапы внесения изменений можно выполнить независимо, а какие зависят от других или требуют целого ряда выполненных условий.
Начинаем с тех изменений, которые можно выполнять независимо и начинаем их вносит по следующему плану: внесли – протестировали – вывялили и устранили проблемы – завершили.
После чего, но не ранее, можно переходить к следующему изменению. Это позволит решать проблемы по мере их поступления, а не все разом. При этом вы всегда будете понимать, с каким именно изменением связана проблема.
Говоря о проблемах следует понимать, что не все из них являются техническими, многие окажутся организационными или просто создадут для конечных пользователей ранее неизвестную им ситуацию, которую они определят как проблему и будут обращаться по этому поводу в поддержку.
В связи с этим важно обеспечить соответствующую работу с пользователями, чтобы своевременно сообщить им обо всех изменениях и новых алгоритмах работы, иначе даже выполнив все технически безупречно вы рискуете провалить внедрение в глазах руководства, потому что вовремя не научили пользователей и не подготовили к новым условиям работы.
После того, как вы последовательно выполнили все изменения текущего уровня переходите к следующим. При этом учитывайте зависимости и всегда оставляйте время на тестирование и выявление ошибок.
Такой подход, даже при достаточно сложных изменениях позволяет сохранить контроль и выполнять поиск возникших проблем точечно, понимая с чем примерно они связаны. Потому что вчера у вас все работало, сегодня вы изменили это и это и получили проблему. Куда смотреть более-менее понятно.
В противном случае вы можете уподобиться герою известного анекдота, который ищет часы не там, где потерял, а там, где светлее.
Даже если проблема комплексная и появляется на пересечении нескольких изменений, то тоже будет примерно понятно это комбо, так как вы всегда будете видеть, какой из добавленных или измененных компонентов привел к проблеме и сможете провести причинно-следственные связи, хотя бы примерно определив предполагаемого виновника.
Ну и не забывайте на каждом этапе документировать все вносимые изменения и полученные при этом результаты, это поможет как вам, так и при возможном обращении в поддержку.
Кстати не стесняйтесь обращаться туда, а откуда еще разработчики должны узнать что в их продукте проблема?
👍35❤1🥱1