четверг, 12 декабря 2013 г.

Обновление сервера 1С 8.2

Ну и, раз я снова здесь для себя оставляю заметочки, оставлю ещё такие. Вдруг пригодится.

Обновление 1C сервера проводится легко за 10-15 минут, при нормально проведённой предварительной подготовке, а именно, обновлении клиентов. Хвала Аллаху, в версиях 8.2 1С перестала, как это было в 8.1, заменять клиента и у пользователя спокойно может жить десяток клиентов 8.2 разных версий, а специальный стартер сам выбирает, в зависимости от версии сервера, к которому подключается, какого клиента запустить.

Поэтому, в день перед обновлением мы, с помощью remoteExec обновляем клиентов (об этом я здесь писал), а утром следующего дня, на сервере устанавливаю новую версию (и если кроме 8.2 на нём ничего не крутится, то на этом всё заканчивается - при установке 1С сама пропишет путь к последней установленной версии платформы в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.2 Server Agent, в параметр ImagePath). Если же есть другие версии 1С, либо просто нужно изменить порты, либо каталог сервера (если запущено несколько серверов 8.2), то в вышеупомянутой ветке всё это редактируется (она должна из себя представлять что-то вроде этого:
"C:\Program Files\1cv82\8.2.10.77\bin\ragent.exe" -srvc -agent -regport 2041 -port 2040 -range 2060:2091 -d "C:\Program Files\1cv82\srvinfo")

Ошибка sql server 8618 при выполнения запроса 1С

После перехода на 1С 8.2.19.76 с 8.2.16.368 столкнулись со странной ошибкой. При выполнении запроса типа

ВЫБРАТЬ поле1, ВЫРАЗИТЬ(Поле1.ПолноеНаименование КАК СТРОКА (1000)) , поле3, поле4

ОБЪЕДИНИТЬ ВСЕ 

 ВЫБРАТЬ поле1, ВЫРАЗИТЬ(Поле1.ПолноеНаименование КАК СТРОКА (1000)), поле3, поле4 

ОБЪЕДИНИТЬ ВСЕ

 ВЫБРАТЬ поле1, ВЫРАЗИТЬ(Поле1.ПолноеНаименование КАК СТРОКА (1000)), поле3, поле4 

УПОРЯДОЧИТЬ ПО поле3, поле4

Вылазит ошибка SQL Server (2005 sp4): Msg 8618, Level 16, State 2

The query processor could not produce a query plan because a worktable is required, and its minimum row size exceeds the maximum allowable of 8060 bytes. A typical reason why a worktable is required is a GROUP BY or ORDER BY clause in the query. If the query has a GROUP BY or ORDER BY clause, consider reducing the number and/or size of the fields in the clause. Consider using prefix (LEFT()) or hash (CHECKSUM()) of fields for grouping or prefix for ordering. Note however that this will change the behavior of the query.

Методом проб и ошибок, было выяснено, что если убрать из запроса поле1 и поле1.ПолноеНаименование, являющиеся реквизитами ТЧ документа с составным типом (два разных справочника с похожей структурой), ошибка пропадает. Так же, ошибка пропадает если убрать сортировку, но, поскольку в печатной форме важен порядок строк, варианты не подходят.

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

Это так, чтобы не забыть самому.

среда, 15 мая 2013 г.

Действительно ли "Белый интернет" такой белый?

Где-то с неделю назад, увидел в новостях такое чудо: "Омские эсеры создают кибердружину".
По ссылке, есть такой комментарий от эсеров:
«Есть, условно говоря, сайт, в который зашиты слова и символы. И если мы заходим через Wi-Fi в каком-нибудь кафе на этот сайт, он может не открыться, так как будет заблокирован технически, либо он откроется. Если сайт не открывается, то мы клеим стикер, что детям здесь находиться безопасно, потому что через местную точку доступа Wi-Fi они не смогут наткнуться на вредоносный контент. Если этот сайт откроется, то мы клеим наклейку, что здесь небезопасно детям, и сообщаем об этом в федеральное движение и администратору кафе».
Я сначала не понял, что это за "условно говоря, сайт, в который зашиты слова и символы" и подумал, что, в общем-то, идея неплохая. А потом вспомнил как мы пытались запретить доступ к соцсетям на заводе. И нихрена у нас не получилось. Прокси, анонимайзеры и прочая хрень, плюс интернет на личных сотовых телефонах, с которых пользователи и выходили на свои вконтактики, одноклассников и прочее. В итоге, на затею плюнули, не доделав до конца - vk.com не открывается и ладно. При этом, у нас был полный доступ на компьютеры пользователей, стоит нормальный железный шлюз и фаерволл - не просто wi-fi-роутер с незапароленной точкой доступа.
Мне стало интересно как проверяют "кибердружинники" - является ли интернет "белым" или нет. Я спросил об этом у Анны Чжен в жж и получил такую ссылку http://www.whiteinternet.info/. Дальнейших комментариев на свои вопросы в этом жж (мой следующий комментарий там был автоматически отмечен как "подозрительный" и в списке комментов так и не появился) и твиттере Сергея Сопко я не получил (может быть их просто ещё не увидели), но, как я понял, вот что они делают.
Открывают сайт http://www.whiteinternet.info/:
Тыкают на кнопку "Проверить интернет", которая ведёт на сайт http://liveporevo.com/, содержащий... Да нихера не содержащий, кроме облака тэгов:
И, если интернет "белый", то эта страница открыться не должна. А если открывается  - то - тадам! - интернет серый и для детей опасный. Но вот в чём проблема - никто ведь не проверяет открываются ли настоящие сайты с порнухой и наркотой. Т.е. тому, кто предоставляет доступ в интернет, достаточно запретить доступ к одному-единственному сайту для того, чтобы получить шильдик "Белый интернет", ничего больше не делая!
Причём запрет доступа к этому ресурсу по ip-адресу - это единственный стопроцентный способ блокирования этой страницы, поскольку на ней вообще не содержится запрещённого контента! Если слова в облаке тэгов считать запрещённым контентом - то должны быть заблокированы и все новостные сайты, рсс-агрегаторы и куча других честных сайтов, на которых могут встретиться нежелательные слова.
Плюс, вспоминая Талеба - "если во взятой пробе не содержится раковых клеток - это не означает, что человек не болен раком - это всего лишь означает, что раковых клеток в пробе нет". Т.е. по данной выборке (да и вообще, по выборке по самым популярным порно-ресурсам, например), нельзя сделать вывод, что здесь "интернет безопасен для детей".

Ну и, вчера вечером шёл с почты и увидел на доме надпись краской: "Спайсы, проба, skype: login". Можно ли теперь считать те места с открытым wi-fi, где я могу пользоваться скайпом, "белым" интернетом?

пятница, 12 апреля 2013 г.

Запоздалая подборка постов по SQL Server

1. So you think you’re a SQL MCM. Test Yourself Part I (Part II, Part III, Part IV)- Bob Duffy предлагает проверить себя - настолько ли хорошо вы знаете SQL Server, насколько хорошо его должен знать SQL Server Master.

2. Moving A Database to New Storage With No Downtime - Bob Pusateri рассказывает о том как можно перенести БД на другой сервер с минимальным временем простоя.

3. Administering SQL Server 2012 running on Windows Server Core - Thomas LaRock об администрировании SQL Server 2012, установленного на Windows Server Core.

4. Filegroups and Non-Clustered Indexes - Rob Farley отвечает на вопрос - в какой файловой группе будет создан некластерный индекс, если файловая группа не указана явно.

5. Log Shipping FAQ - небольшой FAQ по доставке журналов от Jes Schultz Borland.

6. Managing the SQL Server Transaction Log: Dealing with Explosive Log Growth - Tony Davis и Shawn McGehee о причинах и методах решения проблем с растущим журналом транзакций.

7. Forum Etiquette: How to post data/code on a forum to get the best help - Jeff Moden приводит рекомендации относительного того, как правильно оформлять свои вопросы по SQL Server на форумах.

8. Execution Plans in Azure SQL Database - пост Grant Fritchey о планах выполнения в Azure.

9. SQL Server's Auto Update Statistics Async option - Tibor Nagy рассказывает о том, как работает Auto Update Statistics Async и когда эту настройку лучше не использовать.

10. Day 31 of 31 Days of Disaster Recovery: Backup and Restore of the Resource Database - заключительная часть серии постов о Disaster Recovery от Robert Davis, в которой он рассказывает о том как сделать резервную копию (и восстановить её) сердца SQL Server - ResourceDB.

11. Upgrading to SQL 2012: Ten Things You Don't Want To Miss - на что обязательно следует обратить внимание при переходе на SQL Server 2012 от Thomas LaRock.

12. DBCC CHECKDB Execution Memory Grants – Not Quite What You Expect - Jonathan Kehayias показывает, что поведение DBCC CHECKDB отличается от ожидаемого, если не может получить столько памяти, сколько хочет.

13. What is the Difference Between Physical Sockets, Physical Cores, and Logical Cores? - Microsoft, с выходом SQL Server 2012, поменяла модель лицензирования - Glenn Berry описывает как понять за что теперь нужно платить.

14. [Video] Bad SQL Server Advice for DBAs - традиционное 30-минутное видео от Brent Ozar. На этот раз о "плохих советах" для DBA.

15. Managing SQL Server Statistics - что такое статистика, как её использует SQL Server и как с ней правильно работать - в посте Erin Stellato.

16. Partitioning in SQL Server: Managing Sliding Window Scenario - Arshad Ali о секционировании в SQL Server

Ну и ещё несколько постов и ссылок не первой свежести, но не менее интересных:

1. CHECKDB (Part 6): Consistency checking options for a VLDB - что делать, если время выполнения DBCC CHECKDB превышает время вашего окна для обслуживания БД от Paul Randal.

2. Две главы из книги Kalen Delaney, S. Agarwal, C. Freedman, A. Machanic, R. Talmage "Inside Microsoft® SQL Server™ 2005: Query Tuning and Optimization" в свободном доступе на MSDN.

3. DMVs for Query Plan Metadata - Louis Davidson и Tim Ford рассказывают о DMV, с помощью которых можно совершить "deep dive" в планы выполнения.

четверг, 11 апреля 2013 г.

Посмотрел сегодня одну из видеозаписей акций "стопхама". Вообще, у меня неоднозначное отношение к этим ребятам, но сейчас не об этом. В видео не было ни драк, ни особой ругани, народ как-то относительно спокойно разъезжался, когда им говорили, что они криво стоят. Но вот один паренёк, перед тем как срулить, сказал нечто вроде: "Вы вообще молодцы! Я вас вообще всегда поддерживаю, просто вот девушка...".
И вот думаю я про него - ведь ты же всё понимаешь - понимаешь, что стоишь как мудак, что мешаешь людям - так что же ты, сука, делаешь? Почему так?
Мы с детства знаем, что все правила всегда надо соблюдать. Ну то есть почти всегда. И почти все. Кроме тех, выполнение которых осложнит нам жизнь хотя бы на самую малость... Вот весь этот наш житейский эгоизм приводит к таким проблемам. Тот же самый стопхам - сколько у них было конфликтов? Сотни, а может быть и тысячи. То есть, как минимум у сотни человек (а так же  членов их семей, скорее всего) возникли проблемы из-за желания сэкономить две минуты на поиск свободного места на парковке и пять минут на прогулку от этой парковки до нужного места. А ещё тысячи людей в это время, стояли в пробке, возникшей, отчасти, из-за этих товарищей.
Грустно. И глупо.

среда, 10 апреля 2013 г.

alter database rebuild log

Обнаружил на тестовом сервере БД, недоступную пользователями. Когда на этом сервере умер жёсткий диск, большую часть баз я перенёс, какие-то просто убил за ненадобностью, а про эту, получается, просто забыл.
Проблема с этой БД была в том, что раньше у неё журнал транзакций лежал на диске E, теперь такого диска на этом сервере не было в принципе, а журнал транзакций располагался по тому же пути, но на диске D.
С помощью ALTER DATABASE hd_ts MODIFY FILE (name = 'hd_ts', filename = 'D:\bases\hd_ts_log.ldf') я показал, что журнал транзакций теперь живёт в другом месте. Файл этот, к сожалению был повреждён и база данных упала в SUSPECT.
Я выполнил ALTER DATABASE hd_ts SET EMERGENCY и SET SINGLE_USER, после чего с hd_ts появилась возможность делать хоть что-то. Выполнив DBCC CHECKDB ('hd_ts') WITH NO_INFOMSGS, я увидел, что ошибок не обнаружено, но при попытке сделать ALTER DATABASE hd_ts SET ONLINE, БД снова упала в suspect.
Тут я сделал глупость и удалил сам файл журнала транзакций, после чего ни о каком EMERGENCY речь уже не шла. Почитав форумы, я понял, что DBCC CHECKDB ('hd_ts', REPAIR_ALLOW_DATA_LOSS), скорее всего спасло бы меня. Но, что делать сейчас, было непонятно.
Сделать DETACH БД SQL Server не давал, а останавливать сервер на котором крутится десяток других тестовых баз ради того чтобы спасти никому ненужную БД, было бы не логично. В принципе, если бы я мог остановить сервер - потом можно было бы сделать CREATE DATABASE FOR ATTACH_REBUILD_LOG, либо attach_single_file_db и проблема была бы решена. И вот, наткнулся на такую "недокументированную" возможность ALTER DATABASE:
ALTER DATABASE hd_ts REBUILD LOG ON (name = 'hd_ts_log', filename = 'd:\bases\hd_ts_log.ldf'). Вуаля, база жива.

вторник, 2 апреля 2013 г.

Планы

Две недели уже не делал подборку постов по SQL Server'у - их есть у меня, но не очень много. Думаю, что в пятницу сделаю - сразу за три недели.
Сейчас занят тем, что учусь писать на C#. Хочу стать хотя бы junior'ом - такие вакансии периодически попадаются. Мечты оставаться и развиваться как dba, похоже, так и останутся мечтами. На заводе мне двигаться дальше уже некуда, а вообще таких вакансий по Омску я видел ровно одну. Завёл себе "pet project", как все советуют и пытаюсь его запилить. Никому кроме меня он, я так полагаю, не нужен, а мне, в общем-то пригодится.
Жизнь идёт.

пятница, 15 марта 2013 г.

Подборка постов по SQL Server за неделю

Из-за болезни, на прошлой неделе, по работе не читал вообще ничего, а ссылки, тем временем, всё копились и копились. В итоге, большая подборка, за две недели.

1. Twitter Talk Theatre, Episode 1: “RAID is good enough!” - небольшой опрос Jen McCown  на тему - почему наличие RAID-массива не отменяет необходимости в бэкапах.

2. FAQ around sys.dm_db_index_usage_stats - Nacho Alonso Portillo отвечает на вопросы о sys.dm_db_index_usage_stats - DMV, предоставляющем информацию об использовании индексов.

3. Steps to Move SQL Server Log Shipping Secondary Database Files - Jugal Shah о том, как изменить физическое расположение БД, задействованной в log shipping, не перенастраивая этот самый log shipping.

4. How to recover a SQL Server login password - Geoff Albin о том насколько сложно "взломать" пароль, зная его хэш.

5. Hidden Tricks To SQL Server Table Cleanup. Как быстро удалить множество записей из таблицы? Об этом пишет Edward Polley.

6. Benchmark SQL Server Disk Latency - John Sterrett о том, как оценить производительность (точнее latency - задержки) жёстких дисков с помощью встроенных средств SQL Server.

7. Deleting large number of rows from a table in a VLDB - ещё один пост об удалении большого количества записей. На этот раз от Nakul Vachhrajani.

8. Transaction Log Configuration Issues - у журнала транзакций не так уж много настроек, но и их достаточно для того, чтобы обрести проблемы с производительностью. Как этого избежать рассказывает Paul Randal.

9. A Look At DBCC CHECKCONSTRAINTS and I/O - Erin Stellato пишет о том, как выполнение инструкции DBCC CHECKCONSTRAINTS влияет на производительность системы.

10. Disabling vs. Dropping Indexes - в какой ситуации индекс нужно удалять, а в какой достаточно его запретить? Об этом пост Jes Schultz Borland.

11. Autogrowth option for SQL Server database files - BatuhanYildiz пишет о том как влияют на производительность параметры Autogrowth для файлов данных и журналов транзакций.

12. THAT’S ACTUALLY A DUPLICATE INDEX - Jason Strate об обнаружении дублирующихся индексов.

13. Getting Started with Extended Events in SQL Server 2012 - в SQL Server 2012 появился удобный GUI для работы с Extended Events. Robert Sheldon рассказывает как им пользоваться.

14. Log Shipping Part 2: When Disaster Strikes (video) - получасовое видео от Jes Schultz Borland о том, что делать в случае "пожара" - как мониторить и делать fail-over на другой сервер при наличии Log Shipping.

15. Did You Restore It? - Chris Shaw о необходимости тестирования сделанных бэкапов.

16. Custom Log Shipping - пост от Chris Kempster о том как настроить Log Shipping без GUI.

17. CHECKDB From Every Angle: Complete description of all CHECKDB stages - подробнейшее описание того, как на самом деле работает и что делает DBCC CHECKDB от Paul Randal.

Замена Google Reader

Достаточно давно пользуюсь гугл ридером и вчерашняя новость о том, что с первого июля его прикроют, меня достаточно сильно расстроила. В интернетах даже подписывают петицию в гугл для сохранения ридера, но сильно сомневаюсь, что она хоть как-то подействует.
На том же самом хабре, уже предложены альтернативы, но все они какие-то "не такие". Сейчас пробую привыкнуть к feedly (надо сказать, что при логине через гугловский аккаунт, все подписки успешно перенеслись), но всё равно чувствую, что что-то не так :).
На хабре появился большой пост с альтернативами, огорчает, что многие из них платные.

среда, 13 марта 2013 г.

Вчера "Авангард" проиграл всухую третий матч в серии с "Трактором" и у меня всплыл ещё один интересный момент из "Чёрного лебедя". Н.Н.Т. там использует такой пример.
Он предлагает двум людям - по одному из Среднестана и Крайнестана - рассчитать вероятность того, что при подкидывании монетки на 100-й раз выпадет решка. При этом уточняет, что монетка у него идеально сбалансированная, но при предыдущих 99-ти подкидываниях подряд, выпадал только орёл. Человек из Среднестана, по его словам, даст вероятность выпадения решки 50%, а человек из Крайнестана скажет, что такая вероятность не больше 1%, поскольку, раз в предыдущих 99-ти опытах подряд выпадали только орлы, то либо с монеткой что-то не так, либо подкидывающий хитрит.
И вот глядя на игры "Авангарда", я думаю, что если "монетку или подкидывающего не заменят", то сегодня шанс выиграть у нас не более 1%.

вторник, 12 марта 2013 г.

Ошибки восприятия

За время проведённое на больничном, полезного я сделал совсем немного. Даже больше - совсем ничего. Единственное, что было несколько полезно для меня - это то, что я прочёл "Чёрного лебедя" Талеба.
Первое упоминание об этой книге я увидел в компьютерре совсем недавно, потом статьи в википедии и по ссылкам оттуда. Ну и в конце концов, добрался до книги.
Читалась она, надо сказать, тяжело. Вроде бы и нет формул, нет каких-то совсем уж "заумностей", но шла она с огромным трудом. Свою роль в этом, наверное, сыграло то, что читал я книгу на телефоне и вернуться к предыдущим главам, чтобы что-то уточнить было тяжелее, чем с бумагой (пролистать бумажную книгу и найти интересующий фрагмент гораздо удобнее). Боюсь, что понял я из этой книги совсем немного.
Не буду сейчас говорить о самих "чёрных лебедях" (хотя, по сути, сам мой больничный, лично для меня, стал таким "чёрным лебедем", хотя жена сказала - "Ну я же говорила, что надо было к врачу идти раньше"). Меня заинтересовала в книге мысль об ошибках восприятия (или интерпретации) - это термин не из книги, не помню как там это звучало, а моя "интерпретация". Суть в следующем: Н.Н.Т. (как сам себя именует автор в книге) приводит такой пример - у человека с подозрением на рак берут часть клеток (пункция, или как там это называется) и, если в этом образце раковых клеток не обнаружено, говорят, что раком он не болен. Но это не обязательно правда. Вот если бы раковые клетки были обнаружены - тогда можно было бы со стопроцентной уверенностью сказать, что рак есть. Но то, что во взятой пробе не обнаружено раковых клеток, вовсе не означает, что их нет в "соседних" клетках. И мы, в своей жизни, часто ошибаемся таким образом.
Меня этот пример заинтересовал вот чем. У SQL Server есть такое свойство БД как "модель восстановления" (возможно, однажды я-таки подробно их разберу). Внешне у них есть такое различие. Если у БД стоит "простая" (simple recovery model) модель восстановления, её журнал транзакций, обычно, представляет собой небольшой файл, который не растёт с течением времени. Если же у БД "полная" (full recovery model) модель восстановления, то её журнал транзакций постоянно увеличивается в размерах (при определённых условиях, но эти условия обычно возникают именно у тех, кто допускает ту самую ошибку восприятия о которой я расскажу чуть дальше).
Т.е., если представить, что на одном сервере баз данных есть две абсолютно одинаковых БД, в которых одними и теми же людьми производятся одни и те же действия, то у БД1 (с моделью восстановления simple) журнал транзакций будет занимать, например, 256 мегабайт, какие бы действия с базой не производились, а у БД2 (с моделью восстановления full), при тех же самых действиях с БД, журнал транзакций может, через какое-то время, занимать и 100 гигабайт и продолжит расти до тех пор, пока не займёт всё свободное место на жёстком диске. Человек, понимающий как работает SQL Server с моделями восстановления, не увидит в этом ничего удивительного, а человек, не знающий этих "особенностей" часто делает такой вывод:
При использовании модели восстановления simple, SQL Server не использует журнал транзакций (ничего не записывает в журнал транзакций), объясняя это тем, что журнал транзакций, с течением времени, не изменяется в размерах.
Этот пример всплыл у меня в памяти, потому что я неоднократно разубеждал в этом пользователей на форумах, но не уверен, что у меня получалось.
Вообще любопытно. Надо внимательнее понаблюдать за собой, вполне вероятно, что у меня так же куча "ошибок восприятия".

пятница, 1 марта 2013 г.

Подборка постов по SQL Server за неделю

Очередная подборка постов по SQL Server, понравившихся мне на этой неделе.

1. Полезная информация по зеркальному отображению баз данных от Don Castelino.

2. Как и что именно хранится в файлах MDF и LDF, плюс 30 минутный вебинар, посвящённый этой же теме от Brent Ozar.

3. Как узнать сколько ещё будет работать SQL Server Evaluation Edition пишет G Bowerman

4. Отличная серия постов по disaster recovery от Robert Davis ("зеркало").

5. В том случае, если нужно установить несколько SQL Server с одинаковыми настройками, поможет пост Jugal Shah. 

6. Пост о влиянии плана энергосбережения процессора на производительность SQL Server от Bradley Ball.

7. Ещё один вебинар от Brent Ozar, на этот раз посвящённый настройке log shipping.

8. Отличный каталог утилит (как платных, так и бесплатных) для SQL Server на mssqltips.com.

9. 15 вопросов и ответов для интервьюирования разработчиков SQL Server от Thomas Kovarik.


среда, 27 февраля 2013 г.

Открыл для себя очередную группу - Blackfoot Sue. Напоминают, временами, горячо любимых Slade.
Лучшее из того, что я слушал за последнее время.

ДДУ, 214 ФЗ и прочая непонятная хрень

В начале ноября заключили договор уступки на покупку квартиры по договору долевого участия в строительстве, зарегистрировали в юстиции, посмотрели сроки сдачи 14.01.2013-15.02.2013 и были рады.
16.01.2013 позвонил я застройщику и спросил когда уже ключи будут выдавать. А застройщик мне молвит человеческим голосом - а мы из-за декабрьских морозов (видимо, изначально планировалось в Сочи этот дом строить и особенности температурного режима Сибирского Федерального Округа учтены не были) сроки переносим, давайте заключать дополнительное соглашение к договору о переносе сроков. Я у них спрашиваю - а насколько вы сроки переносите? Они отвечают уклончиво, мол, разрешение на строительство у нас выдано сроком до 31.03.2013, вот к этому времени сдать и должны. Я им сказал, что подумаю.
И подумал я вот что - если они мне сами позвонят и предложат подписать доп. соглашение, то я, пожалуй, не буду выпендриваться - всё-таки к тому что сроки сорвут я был готов. Но они звонить всё не решались и подумал я, что пусть так всё и остаётся. Однако, недавно, где-то 20.02.2013, звонят мне родители и говорят, что на моё имя пришло заказное письмо. Поскольку  адрес, при заключении договора, я указывал по прописке (ибо хрен его знает где мы завтра жить будем, а у родителей вроде как стабильность), то подумал, что письмо от застройщика. И вот вчера, 26.02.2013, выяснилось, что был прав.
Получил письмо, а там русским по белому написано, что были произведены замеры квартиры и квартира моя оказалась на 0,7 квадратных метра больше, чем в договоре указано. Т.е. застройщик от меня денюжек на 28,5 тысяч рублей меньше получил, чем хотелось бы. И пишут они, что в течение 20 дней эти деньги они очень бы хотели получить.
А сегодня звонят мне и наивным женским голосом спрашивают когда я буду так добр, что соизволю явиться и подписать доп. соглашение о переносе сроков. Т.е. с меня они деньги хотят в полном объёме получить, а вот за срыв сроков строительства они мне неустойку платить не хотят. В общем, будем смотреть что можно сделать. Вечером надо будет изучить договоры (вчера, увы, не успел) и 214 ФЗ "Об участии в долевом строительстве...", благополучно мной распечатанный.

upd

Сел вечером за изучение ДДУ и договора уступки. В моём ДДУ прописано, что в случае отличия реальной площади от проектной, разница выплачивается либо застройщиком, либо участником долевого строительства, т.е. как и в 214 ФЗ. В интернетах пишут, что обычно добавляется пункт, что такие выплаты не производятся, если реальная площадь отличается меньше чем на 1% от проектной, но у меня этого нет, значит будем платить.
Теперь если дом сдадут не раньше 30.03.2013 - сумма неустойки, которую должен выплатить застройщик за срыв сроков, как раз будет примерно равна сумме которую я им уплачу за доп. площадь. Будем посмотреть.

вторник, 26 февраля 2013 г.

24 Hours of PASS. Russian Edition

21-го марта 2013-го года состоится вторая онлайн-конференция "24 Hours of PASS". Необычность этой конференции заключается в том, что она идёт 24 часа (в идеале, у нас 23 часа). Начинается 21-го марта в 00:00 и заканчивается 21-го марта в 23:00. Всего предполагается 23 часовых доклада.
Зарегистрироваться и ознакомиться с программой можно здесь (там же есть ссылки на записи с прошлогодней конференции).

пятница, 22 февраля 2013 г.

Подборка постов по SQL Server за неделю

Подумал, что надо как-то сохранять ссылки на те посты по SQL Server которые меня заинтересовали. Я их, конечно, и так сохранял - отмечал в rss-ридере, но, думаю, так будет удобнее. Плюс, возможно, такая подборка будет интересна кому-то кроме меня. Постараюсь делать такую подборку каждую пятницу (если будет из чего).

1. DBCC WRITEPAGE: an introduction - пост в блоге Paul Randal, о котором я уже написал раньше, поскольку такая возможность действительно меня очень удивила.

2. Corruption demo databases and scripts - пост всё того же Paul Randal  который я по непонятным причинам пропустил и наткнулся на него совершенно случайно. По ссылке можно найти как готовые БД, так и скрипты для их создания. Особенность этих БД заключается в том, что все они содержат в себе "повреждения" и их можно использовать для каких либо демонстраций, либо для тренировки.

3. SQL Server statistics questions we were too shy to ask - Grant Fritchey отвечает на множество вопросов, связанных со статистикой в SQL Server 

4. SQL Server 2008 Statistics: What does a DBA need to know? - так же посвящён статистике. Matt Bowler рассказывает о том, что с его точки зрения,  о статистике должен знать каждый DBA.

5. Troubleshooting and fixing SQL Server page level corruption - Derek Colley объясняет как разобраться с ошибкой "SQL Server detected a logical consistency-based I/O error".

6. 7 Things Developers Should Know About SQL Server - Brent Ozar, бывший разработчик, MCM, администратор баз данных и консультант рассказывает о том, что начинающие разработчики должны учитывать при работе с SQL Server. Перевод этого поста я сделал на хабре.

7. T-SQL script to keep CPU busy - Pinal Dave приводит пример скрипта, позволяющего загрузить CPU на 100% в течение 30-60 секунд.

среда, 20 февраля 2013 г.

О пользе первоисточников

Увидел у Вячеслава Гилёва в G+ ссылку на его блог, где он наглядно демонстрирует преимущество "железных" машин над виртуальными. Вот так это выглядело:
На картинках отлично видно, что "железная" машина в два с лишним раза уделывает виртуалку по производительности. Успех, вроде как. Но, вот по ссылке на первоисточник, всё совершенно не так:
Т.е. у человека, проводившего "исследование", виртуалка уделала живую машину, а не наоборот, как говорит об этом Вячеслав.
Ну и ещё один скрин комментов с инфостарта, где автор исследования говорит, что он не ошибся и у него виртуалка действительно работает быстрее (точнее говоря, не виртуалка работает быстрее, а тест показывает больше "попугаев"):

Ситуация, конечно, странная, но использовать результаты опыта "наоборот" - это как-то не очень правильно.

upd
На инфостарте нашлось объяснение таким результатам - энергосбережение процессора (к вопросу о вреде этой штуки на серверах, кстати). Теперь результаты как в блоге Гилёва, так и на инфостарте выглядят так:
Виртуалка, как и ожидалось, показывает меньше попугаев, но не в 2 с лишним раза, а практически столько же. Отставание от физической машины незначительное.

Как пишет Вячеслав в своём блоге: "Выводы делайте сами...". :)

понедельник, 18 февраля 2013 г.

SQL Server. DBCC WRITEPAGE. Ещё одна недокументированная функция

Закончив с учёбой и появивишись на работе, добрался до гугл ридера. Там меня ждал вот такой вот пост Пола Рэндала, посвящённый недокументированной DBCC WRITEPAGE (какой-то месяц недокументированных команд SQL Server прям).
Название, в принципе, вполне себе говорящее. Она позволяет "на лету" подправить содержимое ЛЮБОЙ страницы в БД.
Пол говорит, что эта штука может использоваться коммандой SQL Team для починки БД клиента. Плюс с её помощью можно испортить себе БД для тестов, либо наоборот на лету починить повреждённую БД (в том случае если есть полная уверенность в своих действиях).
Синтатксис у неё простой:
dbcc WRITEPAGE ({'dbname' | dbid}, fileid, pageid, offset, length, data [, directORbufferpool])
(
проверить, что синтаксис не отличается от приведённого выше, можно очень просто:
DBCC TRACEON (2588);
GO
DBCC HELP ('WRITEPAGE');
GO
)
, где offset - смещение в байтах относительно начала файла (начало файла = 0), length - длина изменения в байтах (от 1 до 8), data - новые данные для вставки (в 16-м виде, '0xAABBCC' - пример строки длиной три байта), directORbufferpool - должен ли быть задействован buffer pool (да - 0, нет - 1).
Последний параметр очень важен. Если вы укажете, что buffer pool задействовать не нужно, то запись будет произведена непосредственно на диск! Это значит, что SQL Server не пересчитает контрольную сумму, и при попытке чтения изменённой страницы, появится сообщение о повреждении страницы.
Пример такого повреждения можно посмотреть непосредственно в блоге Пола Рэндала, ссылка есть в начале моего поста.

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

воскресенье, 17 февраля 2013 г.

Обучение в Softline. Итоги.

Курс закончен, сертификат получен. Попытаюсь разобраться, что этот курс мне дал.
Собственно, не так уж много. Первое - я потыкался с SecretNet'ом. Второе, узнал немного о проведении проверок и получил вполне очевидные рекомендации. Третье - узнал о WingDoc. Если мы будем защищаться целиком своими силами - он может быть полезен. Четвёртое - немного узнал о Microsoft NAP. Вот его мы, возможно, когда-нибудь используем. Пятое - методика расчёта риска от Digital Security, с ней нужно разбираться, но первое впечатление таково, что это может быть полезным при работе. Ну и последнее - некоторое представление об ITIL и PMBok, хотя, про них нужно почитать самостоятельно, чтобы понять будет ли мне это полезно хоть когда-нибудь (словам лектора верить очень сложно, после того как он расшифровал ITSM как IT Security Management и два часа рассказывало том, что этот раздел посвящён исключительно ИБ).
В общем, после курсов у меня появилась "пища для размышлений", но шесть дней на это всё - это перебор. Курс можно было бы упихнуть в пару дней, либо в пяток вебинаров - было бы дешевле и без такого значительного отрыва от производства.

пятница, 15 февраля 2013 г.

День пятый. Ватный.

Учитывая, что вчера мы закончили практически всё, сегодняшний день был чрезвычайно ватным. Единственное более-менее интересное, что было сегодня - это ссылка на http://csrc.nist.gov - кучу американскх рекомендаций по ИБ, первые из которых относятся аж к 1995-му году, а последние к декабрю 2012-го.
В конце дня потыкались в WingDoc, о котором уже было упоминание несколько дней назад. Запросили демо-версию и обнаружили, что эта демка умеет делать только акты классификации ИСПДн, т.е. на модель угроз посмотреть не получилось. Плюс, выяснилось, что даже акт классификации она нам не сформирует, поскольку на машине не установлен Word, без которого документы не формируются.
В общем, в очередной раз я убедился в том, что русские поделки для ЗИ, с сертификатами ФСТЭК, создаются не для улучшения защиты, а исключительно для выкачивания денег.

четверг, 14 февраля 2013 г.

Четвёртый день

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

Поигрались ещё немного с SecretNet, с контролем целостности. Сегодня всё получилось нормально. Выбрали файлы для отслеживания и действие при нарушении целостности. Действия зависят от того как именно эта целостность контроллируется - либо с помощью хэш-функции, либо с помощью сравнения содержимого (т.е. SecretNet может в качестве эталона запомнить всё содержимое нужного файла). Если используется хэш-функция - SecretNet может либо проигнорировать это нарушение, либо заблокировать компьютер, либо заменить эталонное значение на изменённое. Т.е. при первом варианте, в журнале SecretNet'a появится запись о нарушении целостности, во втором тоже самое плюс заблокируется компьютер, в третьем - запись в журнале и замена эталонного значения. При этом, вернуться к эталону будет невозможно! Т.е. мы узнаем, что файл отличается от эталона, но что там был за эталон мы никогда не узнаем. Если же мы, например, будем проверять целостность операционной системы и вирус изменит содержимое какого-то файла, то, при неправильной настройке, "испорченный" файл может стать эталонным...
Для того, чтобы появилась возможность "вернуться" SecretNet в качестве эталона может использовать всё содержимое исходного файла. В этом случае, можно просто заменить контролируемый изменённый файл из сохранённого значения. То же самое произойдёт при удалении файла.

Спросил про то как правильно организовать "поздравлялку" с днями рождения. У нас используется программа birthday - она выводит "сегодняшних" и "завтрашних" юбиляров. Вопрос - какое основание использовать при сборе этих данных?
Предлагается два варианта - первый, в трудовой договор вписывать пункт о поздравлениях. В этом случае не нужно будет брать согласие, а в качестве основания обработки в перечне ПДн можно указать: "исполнение трудового договора". Хотя, конечно, вариант сомнительный.
Другой вариант - в какой-нибудь "кодекс корпоративной этики" добавить "поздравлялочный" пункт, а в согласии и перечне ссылаться на этот кодекс. Тут есть одно большое НО - когда я составлял перечень ПДн на заводе, находил информацию о том, что в качестве основания нельзя использовать локальные акты - только законы и НПА, либо Устав. Само-собой, в Устав никто ничего подобного вписывать не будет, поэтому, насколько законным будет вариант с локальным актом непонятно.
Видимо, будем искать третий вариант.

Немного узнал про Microsoft NAP. Должно быть удобная штука для тех организаций, в которые могут подключаться, например, домашние ноутбуки. Принцип примерно такой - в сети хранятся "эталонные" настройки - антивирусная программа, минимальный набор установленных обновлений, ОС, сетевые настройки и, при включении домашнего ноутбука в сеть, настройки ноута сверяются с эталонными. При совпадении ноутбук попадает в сеть, при несовпадении, настройки ноутбука "догоняются" до минимально необходимых и проверка повторяется.
Тоже стоит подумать о применимости. Может быть, если мы-таки доживём до подключения к сети из дома, эта штука и пригодится.

Ну и напоследок, нам дали рекомендации по тому как себя вести в случае проверки:
1. Сразу же после получения программы проверки - собрать всю документацию и, при возможности, дописать недостающее.
2. Оповестить всех сотрудников о предстоящей проверке. Заставить всех "освежить память", чтобы они помнили на основании каких инструкций они получают доступ к ПДн.
3. Документы должны содержать актуальную информацию на дату проверки.
4. Уделить особое внимание:
1) организации пропускного режима;
2) отделу кадров;
3) бухгалтерии;
4) содержимому сайта - тому что общедоступно, возможно, туда могли попасть ПДн не являющиеся общедоступными.
5. Оперативно реагировать на замечания проверяющих. Если исправлять небольшие недочёты по ходу првоерки, возможно, это устроит проверяющих и никаких предписаний выписано не будет.

среда, 13 февраля 2013 г.

День третий. Экватор

Сегодняшний день начался с установки и настройки SecretNet'a. Он используется для контроля доступа к файлам, содержащим ПДн (в т.ч. печати); контроля целостности как файлов, содержащих ПДн, так и операционной системы; контроля устройств.
Контроль доступа осуществляется на основе мандатного или дискреционного механизмов. Дискреционный доступ реализован и в операционной системе (каждому конкретному файлу "назначаются" пользователи, которые могут читать/писать/изменять файл) и не особо интересен. С мандатным интереснее. Во-первых, выделяются категории файлов, например - ПДн, коммерческая тайна и общедоступные данные. Во-вторых, каждому файлу назначается выбранная категория (поддерживается механизм наследования, т.е. можно на папку повешать "гриф" ПДн и все файлы, созданные в ней, или перемещённые туда, будут обладать этим грифом). В-третьих, для каждого пользователя определяется "наиболее серьёзный" гриф, который должен быть ему доступен и имеет ли этот пользователь возможность самостоятельного назначения грифов для файлов. Т.е., если пользователю, например, доступен гриф ПДн, то он сможет видеть все общедоступные файлы и файлы с грифом "ПДн", "коммерческая тайна" будет ему недоступна, а пользователь с правами доступа к коммерческой тайне, будет иметь возможность доступа к данным с любым грифом.
Проблемных мест, к сожалению, хватает. Во-первых, имеется возможность назначения всего трёх видов грифов, один из которых должен быть общедоступным. Это достаточно крупное разделение. Во-вторых, назначение доступных грифов пользователям - оно производится для каждого пользователя, нельзя назначить доступность грифа группе пользователей.
Контроль устройств. С ним всё относительно просто. Выбираются устройства и назначаются разрешения для конкретных пользователей. Удобно тем, что можно каждому пользователю выдать по флэшке и разрешить компьютере втыкать этому пользователю именно эту флэшку, а все остальные накопители запретить. В плане учёта материальных носителей ПДн - очень удобно. Есть возможность назначать права вообще на всё - вплоть до ядер процессора - применимость не совсем понятна, но есть и ладно.
Контроль целостности. К сожалению, сегодня мы с ним разобраться не успели. Смогли выбрать каталог для контроля целостности, создать там пару файлов и задать эталонные значения. Что должно происходить дальше - непонятно - то ли SecretNet должен запретить их изменение, то ли не должен. Ответ получить не смогли. Единственное, что контроль целостности ОС тормозит так сильно, что загрузка ОС вместо привычных 3-4 минут тянулась минут 10. Если на заводе загрузка будет идти столько же - пользователи нас казнят.
Плюс, нам не показывали, но сказали, что есть "центральная административная" консоль, через которую SecretNet можно настраивать в сети удалённо, со своего рабочего места. На курсах в ОмГУ говорили, что при таком варианте все журналы сообщений будут по сети сливаться на центральную машину и генерировать приличный траффик, тут же говорят, что журналы будут храниться локально и их просто можно просматривать с "центральной" машины.

После SecretNet'a некоторое время потратили на модель угроз. Ничего нового не было, всё есть в базовой модели угроз ФСТЭК и их же методических рекомендациях по выявлению актуальных угроз. Единственное, что при определении уровня исходной защищённости ("УИЗ"), можно сыграть на нечёткости формулировок и снизить этот уровень (например под одноточечным доступом в сеть общего пользования можно понимать как отдельный компьютер, "физически подключенный" к интернету, так и шлюз, через который выходит в интернет сотня пользователей).
Кроме того, для составления модели угроз можно воспользоваться программным продуктом WingDoc, он стоит порядка 15 тыр, гуглится легко. Отвечая на вопросы программы, формируется модель угроз и какие-то сопутствующие документы.
До составления модели угроз самостоятельно я не доходил, так что для меня стало открытием, что для актуальных угроз (например, хищение hdd из системного блока без боковой крышки), нужно составлять ещё и список конкретных уязвимостей. Например, для этой угрозы, уязвимости могут быть такими: отсутствие регламента постановки помещения под охрану и, собственно, отсутствие крышки на системном блоке. Каждая из этих уязвимостей должна закрываться отдельно.

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

Составив список актуальных угроз, можно провести классификацию ИСПДн по приказу трёх (который до сих пор никто не отменял) и установить уровни защищённости по постановлению 1119. С классификацией по приказу трёх я не хочу даже связываться, для специальных систем она делается на основании "экспертной оценки" (эксперт считает, что исходя из обрабатываемых ПДн и актуальных угроз, субъекту может быть нанесён значительный/незначительный вред и определяет класс ИСПДн), а вот уровень защищённости, по модели угроз, определяется хорошо. Во-первых, определяется тип актуальных угроз:
1-й, если актуальны угрозы НДВ в системном ПО;
2-й, если актуальны угрозы НДВ в прикладном ПО и неактуальны в системном ПО;
3-й, если угрозы НДВ не актуальны.
Во-вторых, определяется какие ПДн и в каком количестве обрабатываются (специальные, биометрические, иные, общедоступные) и на основании этих двух параметров определяется требуемый уровень защищённости.
Проблема здесь может крыться в том, что не все сертификаты ФСТЭК гарантируют отсутствие НДВ в ПО, на это следует обратить внимание.
В принципе, если ОС сертифицирована и угрозы 1-го типа неактуальны, то ИСПДн завода (с учётом того, что мы обрабатываем иные ПДн менее чем 100 000 человек) нужно будет обеспечить уровень защищённости 3, что вполне приемлимо.
Перечень применяемых мер, для обеспечения требуемого уровня защищённости, будет утверждён ФСТЭКом позднее. В декабре выходил проект их приказа, достаточно сильно раскритикованный в сети.

Далее, после определения уровня защищённости, нужно будет составить ТЗ на создание системы защиты ИСПДн. Желательно по ГОСТу 34.602. Вообще же, для оформления документов, желательно пользоваться ГОСТом 6.30. В этом случае, вряд ли у проверяющих будут претензии как минимум к оформлению.

вторник, 12 февраля 2013 г.

День второй

Второй день на курсах был более насышенным.
Сначала мы быстро посмотрели на возможности Microsoft NAP, о котором я ранее даже не слышал. Правда не совсем понятна область применения. Возможно, при рассмотрении модели угроз, ясность появится.
Максим (наш лектор) рассказывал о технических каналах утечки. Рассказал и забавную историю о том, что при поиске "закладок" ("жучков"), при обнаружении такой закладки, прежде чем сообщать об этом заказчику, нужно направить запрос в ФСБ - узнать не они ли её установили.
Большую часть дня мы потратили на рассмотрение ОРД. Он обратил внимание на то, что когда приходит проверка, проверяющие могут не требовать какие-то конкретные документы для предоставления, а просить информацию в виде: "А каким образом вы закрываете требование 152 ФЗ, ст.19, п2., пп. 8 (например)". Как-то раньше о таком подходе я не задумывался, в основном искал именно список документов, которые требуют проверяющие. Надо будет взять 152 ФЗ, все подзаконные акты и пройтись по ним, составить свой список и сравнить с тем, который он нам дал.
Всего в списке Максима 31 документ, каждый мы быстро рассмотрели, хотя там всё понятно и из названия (типа "Политика безопасности", "Список лиц, допущенных к обработке ПДн" и т.д.).
Кроме того, он даёт такой список работ (в общем виде):
1. Выделение процессов обработки ПДн.
2. Выделение ИСПДн в различные подсистемы.
3. Классификация ИСПДн.
4. ТЗ на СЗПДн.
В принципе, примерно такой же план, давали и в ОмГУ. Первый пункт, этого плана, в свою очередь, делится на следующие шаги:
1. Назначение ответственного и комиссии.
2. Изучение внутренней и внешней ОРД - т.е. всех документов циркулирующих на предприятии.
3. Интервьюирование должностных лиц - определяем кто и что конкретно делает, выделяем цели обработки ПДн.
4. Идентификация точек входа и выхода информации, пути её перемещения на предприятии.
5. Изучение содержимого входящих и исходящих потоков информации - на этом этапе можно попытаться найти лишнюю информацию.
6. Выявление информации обрабатывающейся без использования средств автоматизации и с их использованием.
7. Анализ и уточнение оснований обработки, установка условий начала и прекращения обработки ПДн, определение категорий, обрабатываемых ПДн.
8. Определение структурных подразделений и должностных лиц, использующих ПДн в своей работе.
9. Составление и утверждение перечня ПДн, с учётом целей, оснований и сроков обработки.
В итоге, на выходе будет: перечень ПДн; список лиц, допущенных к обработке ПДн; описание процессов обработки ПДн.

Для описания самих процессов, по словам Максима, удобно использовать нотацию IDEF0, а для описания логики IDEF3. Честно говоря, с трудом представляю себе размер такой схемы для нашего предприятия, но, возможно, для небольших предприятий такой подход подойдёт.

Что будет дальше - будем посмотреть.

понедельник, 11 февраля 2013 г.

День первый

Итак, завершился первый день курсов по обеспечению безопасности персональных данных от софтлайна.
Понравилось, что в отличии от курсов в ОмГУ, на которых я был в 2011-м году, всё происходит намного быстрее и весь курс, в целом, имеет более практическую направленость. Сегодня, за 5 часов, мы бегло прошлись по самому 152 ФЗ и новому постановлению правительства 1119 от 01.11.2012. И это ещё одно отличие от ОмГУ - там мы в декабре 2011-го изучали "старую" версию 152 ФЗ, без "свежих" на тот момент поправок от 25.07.2011. Так же, мы бегло рассмотрели возможности SecretNet и VipNet. В принципе, об использовании SecretNet'а можно было бы подумать, если бы все файлы на шарах были рассортированы по категориям.
Особенно же интересны сегодня были два момента. Первый - это является ли фотогрфия в пропуске биометрическими ПДн или нет. В интернете единого мнения нет. Одни говорят, что по ГОСТу к биометрии можно отнести только один тип фотографий - те, которые используются в загранпаспорте и им подобные - т.е., хранящих, помимо изображения, ещё кучу дополнительных данны (набор контрольных точек, пол и т.д.). Другие говорят, что если эта фотография используется для "установления личности субъекта персональных данных", то она, согласно 152ФЗ (и ПП 1119) является биометрией (ст. 5 ПП 1119). Наш лектор сторонник первой точки зрения. Он говорит, что вообще определение "установление личности" можно найти только в уголовном кодексе и оно возможно только по "настоящей" биометрической фотографии, при наличии специального оборудования. То же, чем занимается охранник на КПП - это "удостоверение тождественности
личности гражданина с лицом,
изображенным на фотографии", что отличается от "установления личности" как идентификация от аутентификации. Т.е. он признаёт, что человек на фото совпадает с человеком, предъявляющим пропуск, но не гарантирует, что в пропуске всё верно (т.е. он не знает, правильно ли там указана фамилия, например). В общем, об этом стоит подумать.
Второй момент - это озвученная лектором позиция ФСТЭК о выходе новых подзаконных актов. "Считайте все выходящие нормативные документы дополнением к уже вышедшим ранее, если явно не указанно обратное". Т.е., в ПП 1119 явно указано, что ПП 781 утратило силу, соответственно, само ПП 781 принимать во внимание не требуется, а вот, например, приказ 58 (дочерний от ПП 781) остаётся действительным до тех пор, пока его явно не опишут как "утративший силу". Позиция неприятная для меня, как представителя оператора, но хотя бы понятная. В принципе, пока в плане проверок нас нет, будем продолжать ждать выхода новых документов.
Ну и ещё один забавный момент. Лектор при мне позвонил какому-то знакомому, работающему у Челябинского лицензиата по ТЗКИ, и спросил сколько будет стоить разработать комплект документации по 152 ФЗ для предприятя, предположительно К2-К3 и получил ответ: "20-25 тыр". Нам же, местные, предлагают разработать комплект документов за 500 тыр (цифра из реального коммерческого предложения). Вот такие дела. Будем ждать следующего дня.