Как вносить изменения в программу

Как правильно вносить изменения в IT-инфраструктуру.

Думаю что ни для кого не представляет секрета, что работа большинства системных администраторов в небольших компаниях практически никак не формализована и не документирована. С одной стороны вроде бы и размах задач не тот и времени в обрез, а с другой все оказывается завязано на одного единственного человека, который «вроде-бы знает, как это все работает». Особенно ярко данная проблема проявляется при необходимости внести какие либо изменения в инфраструктуру.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Поводом для написания данной заметки послужил вполне реальный случай. Администратор одного из наших клентов вносил изменения в движок корпоративного сайта, попутно сделал какие-то настройки на сервере и обновил его. После перезагрузки сервер перестал отвечать на сетевые запросы. Кроме сайта на этом сервере работало корпоративное web-приложение и работа фирмы оказалась практически парализована.

«разрешить этому приложению вносить изменения на вашем устройстве windows 10» — что это такое?

Когда мы приехали, то выяснилось, что администратор не может четко пояснить что-именно он делал, в какой последовательности и зачем. Также не может сказать где лежит последний бекап и можно ли его развернуть немедленно. К счастью ошибку быстро нашли. Администратор забыл (или не знал) что для сетевой карты сервера был отдельно подключен модуль ядра, который слетел при обновлении на новое ядро. Мы просто загрузили старое ядро и восстановили нормальную работу инфраструктуры.

Ситуация, что и говорить, малоприятная, получить серьезный сбой на «ровном месте» — это очень плохой показатель работы админа, который, как правило, сказывается на его зарплате. Можно ли было этого как-либо избежать? Можно. Для управления IT-инфраструктурой давно существует библиотека ITIL, которая содержит набор методик и практических подходов по управлению информационными технологиями. Конечно, внедрение ITIL в работу небольшой фирмы (да и средней тоже) — это что-то из области фантастики, а вот взять на вооружение отдельные моменты можно и нужно.

Обеспечение изменений — один из базовых процессов ITIL, обеспечивающий стабильность инфраструктуры. На его базе мы сделали небольшую «выжимку», которую с успехом применяем в повседневной деятельности. Об этом мы и поговорим в данной статье.

Как показывает статистика, большинство серьезных инцидентов в инфраструктуре происходит именно при внесении изменений. В большинстве случаев это происходит потому, что изменения никак не документируются и производятся без какого-либо планирования. Я думаю, каждый может вспомнить ситуацию, когда по ходу внесения именений «внезапно оказывалось, что . » и дальнейшие события превращались в аврал, чтобы это все хоть как-то начало работать.

Контроль учетных записей в Windows 10 | Как настроить или отключить UAC?

Гораздо хуже, если вы планируете внедрение с привлечением сторонних специалистов, в этом случае выявление таких «неожиданных моментов» способны серьезно увеличить сроки и стоимость проекта, либо вообще поставить под угрозу его реализацию.

Итак. Любое изменение инфраструктуры должно быть спланировано и задокументировано. Это позволит грамотно оценить риски и провести изменения с минимальным влиянием на работу предприятия, даже если они окажутся неудачными. Мы предлагаем следующий способ документирования изменений:

Описание изменений.

В данном пункте постарайтесь коротко и ясно изложить, для чего предназначено данное изменение, какие цели преследует и кто инициатор. Это позволяет впоследствии легко вспомнить, зачем это было сделано, кому это было нужно и сохраняется ли такая необходимость сейчас. Даже если изменение чисто техническое, также укажите это, чтобы потом не вспоминать для чего именно был установлен этот патч или сделана эта настройка.

Описание зависимостей.

Следующий пункт описывает службы, от которых зависит наше изменение, а также те службы на которое оно может повлиять. Это поможет правильно оценить риски и оценить время вынужденного простоя инфраструктуры. Также здесь следует указать критичность вносимых изменений для той или иной службы. Иногда уже на этом этапе следует отказ от изменения, либо его более детальная проработка, если оказывается, что потенциальный риск превышает потенциальную выгоду. Согласитесь, это гораздо лучше, чем сначала сделать, а потом в панике пытаться срочно исправить ситуацию.

Выделение ресурсов.

Еще один момент, о котором часто забывают. Проанализируйте, какие ресурсы требуются или могут потребоваться вашему изменению. Это могут быть процессорные и дисковые ресурсы, требования к наличию свободной памяти, место в стойке, наличие розеток и запаса по электропитанию и т.д.

Подготовка.

Здесь следует указать предварительные действия, которые необходимо провести перед тем, как вносить изменения. Особенно если они связаны с привлечением третьих лиц. Например будет очень неприятно узнать, смонтировав оборудование в новую стойку, что электрик еще не провел сюда электричество или провайдер не выделил необходимый блок адресов и т.д. и т.п. Также укажите необходимое оборудование и материалы, необходимые лицензии на ПО. Здесь ценным подспорьем будет предыдущий пункт, согласно которого вы проверите, что у вас есть, а что нужно докупить или сделать.

Планирование.

Самый важный пункт документации. Он должен как можно более подробно и последовательно описывать все действия по внесению изменений. Сначала укажите более общие этапы, затем перейдите к более частным. Обычно на этом этапе всплывает 90% подводных камней, когда выясняется, что еще нужно сделать это и это, а также чуть не забыли это.

В итоге из «полчаса делов и одна перезагрузка» изменение превращается во вдумчивую работу на пару часов. Подробно укажите действия на каждом этапе и планируемый результат данных действий.

В итоге у вас должен получиться аналог чек-листа в авиации, советуем распечтать один его экземпляр и использовать при внесении изменений. Этим вы сразу убьете двух зайцев: у вас будет перед глазами шпаргалка и вам не придется мучительно вспоминать (или бежать гуглить) забытые ключи команды и вы будете контролировать исполнение всех необходимых этапов. Если вдруг что-то пойдет не так, вы будете четко знать что вы сделали последним и круг поисков проблемы значительно сузится.

Далее отмечаем критичность тех или иных этапов плана, некритичные шаги можно пропустить, проблемы средней важности допустимо решать непосредственно при изменениях, а при возникновении критических ошибок следует сразу переходить к восстановлению.

Здесь вы можете ознакомиться с примером реального плана, который в общих чертах описывает все основные этапы будущего изменения. Многие из этапов данного плана также нуждаются в отдельном планировании. Таким образом двигаясь от общего к частному вы разобьете работу на логически завершенные этапы, каждый из которых будет отдельно документирован. Еще один плюс такого подхода в том, что вы всегда можете показать руководству что именно уже сделано и что еще предстоит сделать.

План восстановления.

Еще один важный раздел, который должен содержать последовательность действий по приведению системы в первоначальное состояние на случай если что-то пойдет не так. Возможно что при составлении данного раздела вам придется значительно скорректировать основной план и дополнить этап подготовки. Приступая к изменениям очень важно убедиться в наличии резервных копий и возможности восстановления из них. Не будет лишним создать резервные копии непосредственно перед изменениями.

Наличие плана восстановления хорошо тем, что в аварийная ситуация не перерастет в авральную, а будет находиться под контролем. Не забудьте четко ограничить временные рамки, по истечению которых вам нужно переходить к восстановлению. Например у вас есть 2 часа, планируемое время изменений — 20 минут, планируемое время восстановления — 40 минут. Следовательно на решение возможных проблем у вас есть час. Т.е. при наступлении времени Ч + 1 ч 20 мин вам следует прекратить все попытки и приступить к восстановлению.

В ряде случаев, если решение возникшей проблемы не очевидно, лучше сразу приступить к восстановлению, уменьшая возможное время простоя. Помните, что вам платят не за то, что вы успешно решили сложную техническую проблему, а за то, что все работает.

Заключение.

Приведенная выше схема позволяет с небольшими затратами эффективно планировать и документировать изменения инфраструктуры. Понятно, что не обязательно выполнять все пункты для небольших изменений, но план внедрения и план восстановления должны быть всегда. Если бы администратор из примера в начале статьи начал составлять план, то выяснил бы, что восстановить систему в разумное время ему не удастся, что заставило бы его или провести соответсвующую подготовку, либо отказаться от обновления до лучших времен, в любом случае простоя фирмы удалось бы избежать.

В тоже время внося изменения в политики безопасности и правила доступа мы настоятельно советуем заполнять описание, чтобы было понятно, для чего и зачем применяется данная политика. Не так давно мы проводили аудит IT-инфраструктуры на одном предприятии. В его ходе выяснилось, что около половины политик неактуальны и не применяются, причем часть из них просто перекрыта нижестоящими политиками, потому как админ не знал для чего и кем введена основная политика, руководство также не могло пояснить ничего внятного, в итоге он просто перекрыл данные политики своими, в последствии инициировав проведение аудита.

В заключение хотелось бы сказать о еще одной полезной функции документирования изменений. Составления плана позволяет грамотно распределить работу между сотрудниками с различной квалификацией, так как сразу становится видно, что можно поручить младшему персоналу, что сделать самому, а что лучше поручить специалистам со стороны. Планирование также позволяет называть реальные сроки, позволяя избегать ситуаций «ты же еще на прошлой неделе говорил, что работы на полчаса».

Также наличие детально проработанных планов, с отметками о выполнении, позволяет избежать конфликтных ситуаций с руководством, которое, не видя немедленного результата от проводимых администратором действий, может считать, что вы ничего не делаете или уделяете вопросу недостаточно времени.

В любом случае приняв правило докуменировать и планировать, даже сугубо для себя, все изменения, включая незначительные на первый взгляд, вы очень скоро заметите, что нештатных ситуаций в вашей работе стало значительно меньше, а следовательно выросла оценка вашей работы как специалиста со стороны руководства, что самым благоприятным образом должно отразится как на материальных результатах работы, так и на перспективах карьерного роста.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Источник: interface31.ru

Внесение изменений в программу для ЭВМ

Изменения в программу для ЭВМ могут быть внесены по заявлению владельца такой программы. В качестве изменений могут быть внесены исправления неточностей в названии программы, наименовании правообладателя, адресе, исправлены орфографические ошибки в словах. Также в зарегистрированную программу для ЭВМ можно внести изменения по нескольким причинам. Причина 1. Изменение названия правообладателя, если произошло переименование правообладателя с сохранением прежнего ИНН. Такое изменение вносится при смене фамилии, имени или отчества физического лица или при смене наименования юридического лица. Причина 2. Изменение состава правообладателей. Такое изменение вносится только по решению суда. В случае, если правообладатели изменены при продаже программы, регистрируется договор отчуждения на программу для ЭВМ. Причина 3. Изменение адреса регистрации физического лица или юридического адреса компании – правообладателя. Причина 4. Изменение адреса регистрации авторов, раскрытых при регистрации программы для ЭВМ. В том числе вносится изменение о смене страны жительства. Причина 5. Изменение представителя правообладателя или его контактных данных. Не подлежат внесению изменения:

• Названия программы;
• Изменение правообладателя в связи с продажей программы;
• Изменение названия правообладателя в связи с реорганизацией компании;
• Изменения программного кода, функционала, свойств программы, а также сферы ее применения.

Порядок регистрации изменений

Заявление на внесение изменений подается в Роспатент. Дополнительно к изменениям производится оплата государственной пошлины в размере 2 000 рублей. Заявление рассматривается и изменения вносятся в срок от 10 до 30 дней.

Что делать, если изменен программный код?

Если произошло изменение исходного кода программы, которое повлекло изменение не только технических характеристик программного продукта (быстродействие и другие), то рекомендуется провести регистрацию новой версии программы для ЭВМ.

Обратите внимание, что повторная регистрация с ранее зарегистрированным названием не допускается. Однако, для успешной регистрации модифицированной программы к ранее существующему названию можно добавить указание на версию продукта.

Источник: trademark-support.ru

Как вносить изменения в унифицированные формы первичных документов в программах 1С?

Чем хорош наш чат «Учет без забот» в Телеграмм, так это тем, что ежедневно туда поступают интересные вопросы, на которые мы стараемся дать ответы. И вот недавно наша подписчица задала достаточно распространенный на линии консультаций 1С вопрос: «Как в программах 1С из табеля рабочего времени убрать поле «работник кадровой службы» и заменить «ответственное лицо» на «бухгалтера», а «руководителя структурного подразделения» на «директора»?» В этой статье мы расскажем, можно ли это делать с точки зрения законодательства, и как такие изменения самостоятельно реализовать в 1С?

Итак, организация имеет право использовать в своей деятельности любые формы первичной учетной документации (унифицированные формы и/или разработанные самостоятельно), содержащие все обязательные реквизиты, перечисленные в ч. 2 ст. 9 Закона № 402-ФЗ. Исключение составляют формы первичных документов, обязательные к применению, например, кассовые документы (информация Минфина России от 04.12.2012 № ПЗ-10/2012).

Формы первичных учетных документов обязательно должны быть утверждены в учетной политике организации (п. 4 ПБУ 1/2008) с учетом следующих особенностей:

1. Если вы будете использовать унифицированные формы документов, установленные Госкомстатом РФ, без их изменения, то в учетной политике можно просто сослаться на применение унифицированных форм документов и привести ссылки на соответствующие постановления Госкомстата РФ.

2. Если вы в своей деятельности будете использовать самостоятельно разработанные формы или унифицированные формы документов, но с дополнительными реквизитами, то образцы форм первичной документации следует утвердить в качестве приложения к учетной политике или отдельным приказом руководителя со ссылкой на этот приказ в учетной политике организации.

Из этого следует, что по закону вы можете изменить форму документа под ваши нужды, не забыв при этом утвердить их в учетной политике.

Как же это всё реализовать в 1С?

Любая печатная форма, будь то документ, или отчем имеет свой макет. Примеры по изменению макетов печатных форм мы уже рассматривали ранее на примере программы 1С: Бухгалтерия предприятия и документе «Счет».

Изменить макет «Табеля учета рабочего времени» не сложно, достаточно найти его и отредактировать.

Рассмотрим действия на примере двух программ: 1С: Бухгалтерии предприятия ред. 3.0 и 1С: ЗУП ред. 3.1.

В 1С: Бухгалтерии предприятия макеты печатных форм доступны в разделе «Администрирование» — «Печатные формы, отчеты и обработки».

Шаг 1. Перейдите по гиперссылке «Макеты печатных форм».

Шаг 2. Найдите в списке форму макета «Табель учета рабочего времени» и нажмите «Изменить».

Шаг 3. Очистите ячейки, которые хотите удалить.

А текст подписей измените на нужный.

Чтобы не «заморачиваться» со свойствами ячеек, и чтобы убрать полоски для подписей, можно полностью удалить строки.

Шаг 4. Выделите строки и, нажав правой кнопкой мышки, выберите команду «Удалить». Сохраните макет – «Записать и закрыть».

В результате изменений в списке макетов, возле измененной формы появится обозначение – «карандашик».

Шаг 5. Перейдите в раздел «Зарплата и кадры» — «Отчеты по кадрам».

Шаг 6. Сформируйте отчет «Табель учета рабочего времени».

Надписи в печатной форме отчета изменены.

В программе 1С: ЗУП макеты печатных форм также находятся в разделе «Администрирование» — «Печатные формы, отчеты и обработки».

Макеты печатных форм находятся в одноименном разделе.

Порядок изменения макета табеля аналогичен рассмотренному выше варианту.

Чтобы вернуть макет, используемый по умолчанию обратно, достаточно выделить нужный макет, нажать кнопку «Еще» и выбрать команду «Использовать стандартный макет».

Автор статьи: Ольга Круглова

Понравилась статья? Подпишитесь на рассылку новых материалов

Источник: xn--80abbnbma2d3ahb2c.xn--p1ai